Кто не делится найденным, подобен свету в дупле секвойи (древняя индейская пословица)
Версия для печати
Библиографическая запись:
The main provisions of the infological approach to database design. The entity-relationship model. — Текст : электронный // Myfilology.ru – информационный филологический ресурс : [сайт]. – URL: https://myfilology.ru//165/bazy-dannyx/the-main-provisions-of-the-infological-approach-to-database-design-the-entity-relationship-model/ (дата обращения: 20.04.2024)
The main provisions of the infological approach to database design. The entity-relationship model
Содержание
Infological data models are used in the early stages of design to describe data structures during application development.
When developing serious corporate information systems, the database project is the foundation on which the entire system as a whole is built, and the question of possible lending is often decided by the bank's experts on the basis of a competently made infological database project. Therefore, the infological model should include such a formalized description of the subject area, which will be easily "read" not only by database specialists. And this description should be so capacious that it is possible to assess the depth and correctness of the development of the database project, and of course, as mentioned earlier, it should not be tied to a specific DBMS. Choosing a DBMS is a separate task, for its correct solution it is necessary to have a project that is not tied to any particular DBMS.
The initial stage of designing a database system is the construction of a semantic domain model, which is based on the analysis of the properties and nature of the objects of the domain and the information needs of future users of the system being developed. This stage is commonly called the conceptual design of the system, and its result is a conceptual model of the subject area (the object of modeling here is the subject area of the future system). The previously mentioned terms "infological design" and "infological model" also correspond to this stage.
Infological design is primarily associated with an attempt to represent the semantics of the domain in the database model. The relational data model, due to its simplicity and conciseness, does not allow you to display the semantics, that is, the meaning of the subject area. Early graph-theoretic models reflected the semantics of the domain to a greater extent. They explicitly defined hierarchical relationships between the objects of the subject area.
The infological model reflects information about the subject area without focusing on a specific DBMS (or even on the type of DBMS intended for use). In this regard, some authors talk about the existence of an infological model of the subject area, and not a database.
Such models generically represent the information needs of users of the system being created in terms of the use of stored data and are essentially a means of communication for both developers and users at different stages of the database lifecycle.
The purpose of infological models also determines some specific requirements for the means of their representation. In addition to the mentioned independence from the environment (equipment) and the requirement of adequate reflection of the subject area, we note the following:
formalized, providing the possibility of automated processing, including, for example, automatic consistency control;
friendliness, which provides the possibility of using visual graphical means of displaying and processing them by the user.
Infological models include various components that reflect the subject area in different ways and by different means.
In addition to the most well—known description of objects and relationships between them (the "entity - relationship" model), the following components can be attributed to the infological level of the description of the subject area:
a system of attributes and means of describing the subject area. For example, logical (algorithmic) relationships between indicators or linguistic properties of the language (synonymy, syntax, etc.) used for the verbal representation of objects;
integrity constraints that determine the validity of the values of individual fields and relationships both at the level of the semantics of the database content and its physical structure (individual data files and relationships between them);
description of the information needs of users, for example, in the form of standard queries reflecting the procedural features of accessing data.
The entity-relationship model
The description of the subject area in the infological model is usually made in terms of "object" - "relation" (a number of authors use the terms "entity" - "connection", English entity - relation, abbreviated ER).
The entity-relationship model is most consistent with the concept of object-oriented design, which at the moment is undoubtedly the basis for the development of complex software systems.
An entity (object) is a set of instances of real or abstract objects of the same type present in the subject area. It is customary to name an entity with a singular noun, for example, "Flight" or "Customer". Entities can be correct (another name is "strong") and weak. The correct entity corresponds to those objects whose existence does not depend on other objects. A weak entity is dependent on other entities (it cannot exist in the absence of some other entity). For example, if an order must always be made by some customer, then the "Order" will be a weak entity dependent on the "Customer" entity. In this example, if no additional conditions are set, then "Client" is the correct entity.
An entity has a set of properties called attributes. Each attribute group describing one real manifestation of an entity is an instance of an entity.
In order for one entity to be distinguished from another, one or more attributes are selected with a unique value (a unique combination of values), which is called an entity identifier. Such attributes are often called key attributes.
Attributes can be:
1) simple and composite;
2) key and non-key;
3) mandatory and optional;
4) unambiguous and multivalued.
Regarding the division of attributes into simple and composite, the following remark can be made. A composite attribute, such as an address, can include a set of values: index, country, city, street, house. When building an infological model, such attributes are acceptable. When switching to a datalogical model, everything depends on the selected data model and the capabilities of the DBMS. For example, there are no composite attributes in the relational model, they will have to be represented as a set of simple ones.
The value of required attributes must always be set. Optional attributes may be missing (not specified). Attributes can also be unambiguous and multi-valued: a company can have only one chief accountant and several phone numbers. When building an infological model of a subject area, it is permissible to specify multi-valued attributes, but when moving to a lower level of design, when it is necessary to take into account the features of the selected data model and DBMS, such attributes may have to be disposed of. In particular, the relational model does not support multi-valued attributes. To solve this problem, an additional relational relation is usually introduced.
Attributes must be set on domains (a domain in this case is a set of valid attribute values). The ER diagrams, which will be discussed below, usually do not specify domains. This information is placed in a separate document called a data dictionary. At the same time, some variants of Chen's notation allow specifying domains in diagrams under the attribute image. Communication (relation) in infological design describes the logical connection between two or more entities existing in the subject area. The objects that connect are called communication participants. The number of participants determines the degree of communication. Just as in the case of entities, the type and instance of the relationship are distinguished. It is customary to name the relationship using a verb, for example, the relationship between the entities "Customer" and "Order" can be called "Places".
Let R be the type of connection, E be the type of entity. If each instance of an entity of type E is located in at least one instance of a relationship of type R, then E's participation in R is called complete or mandatory, otherwise partial or optional. For example, let the subject area under consideration be education, the entities "Teacher" and "Course" are highlighted in it, and the relationship "Reads" is defined between them. If each course is taught by at least one teacher, but there are teachers who do not read any courses, then the participation of the "Course" entity in the "Reads" relationship is complete, and the "Teacher" entity is partial.
The following types of connections are distinguished:
1) one-to-one;
2) one-to-many;
3) many-to-many.
Here are the formal definitions for these types of links.
Let there be two entities (A and B) involved in the connection R. If each instance Aj of entity A is associated with no more than one instance of entity B, and each instance Bj of entity B is associated with no more than one instance of entity A, then the relationship B is of type one-to-one. In practice, this type of communication is quite rare.
A relationship A has a one-to-many type if an instance Aj of entity A can be associated with zero, one or more instances of entity B, and an instance Bj of entity B can be associated with no more than one instance of entity A. The inverse of the one-to-many type is the many-to-many relationship type.k-one.
One-to-many relationships are most common in database development. For example, if one customer can place multiple orders, and each order is made by only one customer, then the relationship between customers and orders will be of the one-to-many type. The relationship between entities A and B will be of the many-to-many type if an instance Aj of entity B can also be associated with zero, one or more instances of entity A. For example, if several teachers can teach one course, and one teacher can teach several courses, then there is a many-to-many relationship between the entities "Teacher" and "Course". In most cases, during the design process, many-to-many relationships are removed by introducing composite (associated) entities and defining two one-to-many relationships.
01.09.2022, 15337 просмотров.