CushionTheBlow (구 BluemoonSoft)

갑자기 E 드라이브의 용량이 실시간으로 줄어들기 시작했다.

C 드라이브였다면 프로그램이 동작하면서 생성하는 임시 파일 때문이려니 하겠지만,

E 드라이브에서 이런 현상이 생기는 것은 이해할 수가 없었다.

처음에는 바이러스를 의심하였다.

'자기 증식을 해서 용량을 고갈시키고 있구나.'라고 생각하였다.

하지만 최신 백신으로 검사하였지만 바이러스는 검출되지 않았다.

결국 용량을 많이 차지 하는 폴더를 대상으로

모든 하위 폴더를 하나하나 검사하기에 이르렀다.

원인은 동일한 파일이 계속 복제됨으로써 발생하였다.

A.xxx, A(1).xxx, A(2).xxx, and so on.

바이러스가 틀림없다고 생각했지만,

잡을 길이 없었다.

시간이 지나서야 알았지만,

네이트온 때문이었다.

바보 같은 네이트온의 파일방이 계속해서 동일한 파일을 가져오는 것이었다.

대략 황당했다...

An entity-relationship model is an abstract conceptual representation of structured data. Entity-relationship modeling is a relational schema database modeling method, used in software engineering to produce a type of conceptual data model (or semantic data model) of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created using this process are called entity-relationship diagrams, or ER diagrams for short. Originally proposed in 1976 by Dr. Pin-Shan (Peter) Chen (陳品山), many variants of the process have subsequently been devised.

The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology (i.e. an overview and classifications of used terms and their relationships) for a certain universe of discourse (i.e. area of interest). In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design".

There are a number of conventions for entity-relationship diagrams (ERDs). The classical notation is described in the remainder of this article, and mainly relates to conceptual modeling. There are a range of notations more typically employed in logical and physical database design, including IDEF1x (ICAM DEFinition Language) and dimensional modeling.

Connection
A sample ER diagramAn entity represents a discrete object. Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem. Entities are represented as rectangles.

A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.

The model's linguistic aspect described above is utilized in the database query language ERROL.

Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute. Attributes are represented as ellipses connected to their owning entity sets by a line.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set.

Lines are drawn between entity sets and the relationship sets they are involved in. If all entities in an entity set must participate in the relationship set, a thick or double line is drawn. This is called a participation constraint. If each entity of the entity set can participate in at most one relationship in the relationship set, an arrow is drawn from the entity set to the relationship set. This is called a key constraint. To indicate that each entity in the entity set is involved in exactly one relationship, a thick arrow is drawn.

Associative entity is used to solve the problem of two entities with a many-to-many relationship.

Unary Relationships - a unary relationship is a relationship between the rows of a single table.

Reference:
http://en.wikipedia.org/wiki/Entity-relationship_model

In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Relationships
A relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships:

Instance-Level Relationships
Link
A Link is the basic relationship among objects. It is represented as a line connecting two or more object boxes. It can be shown on an object diagram or class diagram. A link is an instance of an association.

Association
An Association represents a family of links. Binary associations (with two ends) are normally represented as a line, with each end connected to a class box. Higher order associations can be drawn with more than two ends. In such cases, the ends are connected to a central diamond.

An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties. There are five different types of association. Bi-directional and uni-directional associations are the most common ones. For instance, a flight class is associated with a plane class bi-directionally. Associations can only be shown on class diagrams.

Example: "department offers courses", is an association relationship.

Aggregation
Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association. It is an association that represents a part-whole relationship. As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container--essentially, if the container is destroyed, its contents are not.

In UML, it is graphically represented as a clear diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Composition
Composition is a stronger variant of the "has a" or association relationship; composition is more specific than aggregation. It is represented with a solid diamond shape.

Composition has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, every instance that it contains is destroyed as well.

The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Differences between Composition and Aggregation
The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must be for only one whole. The part of an aggregation may have any multiplicity.

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a car, the composition relationship is most appropriate. However, when representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is best, as the engine, ENG01 may be also part of a different car model, CM02. This is often called a "catalog" relationship

Class Level Relationships
Generalization
The Generalization relationship indicates that one of the two related classes (the subtype) is considered to be a specialized form of the other (the supertype) and supertype is considered as Generalization of subtype. In practice, this means that any instance of the subtype is also an instance of the supertype (An exemplary tree of generalisations of this form is found in binomial nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so on). The relationship is most easily understood by the phrase 'A is a B' (a human is a mammal, a mammal is an animal).

The UML graphical representation of a Generalization is a hollow triangle shape on the supertype end of the line (or tree of lines) that connects it to one or more subtypes.

The generalisation relationship is also known as the inheritance or "is a" relationship.

The supertype in the generalisation relationship is also known as the "parent", superclass, base class, or base type.

The subtype in the generalisation relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type.

Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading.

Generalization-Specialization relationship

- A is a type of B
- E.g. "an oak is a type of tree", "an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.

Realization
In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes the behavior that the other model element (the supplier) specifies. A realization is displayed in the diagram editor as a dashed line with an unfilled arrowhead towards the supplier.

Realizations can only be shown on class diagrams.

A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface.

General Relationship
Dependency
A dependency exists between two defined elements if a change to the definition of one would result in a change to the other. This is indicated by a dashed arrow pointing from the dependent to the independent element. Several named varieties exist. A dependency can be between instances, classes, or both.

Multiplicity
The association relationship indicates that (at least) one of the two related classes makes reference to the other. In contrast with the generalization relationship, this is most easily understood through the phrase 'A has a B' {a mother cat has kittens, kittens have a mother cat}.

The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association). Common multiplicities are:

0..1 No instances, or one instance (optional, may)
1 Exactly one instance
0..* or * Zero or more instances
1..* One or more instances (at least one)

Reference:
http://en.wikipedia.org/wiki/Class_diagram