How To Represent Composite Attribute In Er Diagram

23 Dec, 2021 Post a Comment

Composite Entity

Entities and Relationships

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

Composite Entities

Entities that exist to represent the relationship between two or more other entities are known as composite entities. As an example of how composite entities work, consider once again the relationship between an order placed by an Antique Opticals customer and the items on that order.

What we need is an entity that tells us that a specific title appears on a specific order. If you look at Figure 4.13, you will see three order instances, and three merchandise item instances. The first order for customer 0985 (Order #1) contains only one item (item 02944). The second order for customer 0985 (Order #2) contains a second copy of item 02944, as well as item 10101. Order #3, which belongs to customer 1212, also has two items on it (item 10101 and item 00250).

There are five items ordered among the three orders. The middle of the diagram, therefore, contains five instances of a composite entity we will call a "line item" (thinking of it as a line item on a packing slip or invoice). The line item entity has been created solely to represent the relationship between an order and a merchandise item.

Each order is related to one line item instance for each item on the order. In turn, each item is related to one line item instance for each order on which it appears. Each line item instance is related to one and only one order; it is also related to one and only one merchandise item. As a result, the relationship between an order and its line items is one-to-many (one order has many line items) and the relationship between an item and the orders on which it appears is one-to-many (one merchandise item appears in many line items). The presence of the composite entity has removed the original many-to-many relationship.

If necessary, the composite entity can be used to store relationship data. In the preceding example, we might include an attribute for the quantity ordered, a flag to indicate whether it has been shipped, and a shipping date.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000041

Relational Databases and "Big Data": The Alternative of a NoSQL Solution

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

Graph

A graph NoSQL database is made from nodes that are similar to rows in relational database tables. However, rather than using composite entities to show relationships and to store relationship data, graph databases use a representation of the relationships; the relationships can have properties, just like a composite entity stores relationship data. The result is something that looks like a mathematical directed graph.

The biggest advantage of the graph store is that joins aren't necessary. The pathways between related data exist within the database. As an example, consider the graph in Figure 28.1. It shows six instances of nodes from an Antique Opticals database.

The price charged the customer and the quantity ordered are properties of the Contains relationship. There is no composite entity between the order and the inventory item. To retrieve data, the DBMS follows the relationships stored in the database.

Note: Graph databases are navigational, like the data models discussed in Appendix A , because access to data follows predefined paths. However, the stored relationships in the older data models cannot have properties.

Graph databases are well suited to large databases that must track networks of relationships. They are used by many online dating sites, as well as LinkedIn and Twitter. Avoiding the joins to traverse friend relationships can speed up performance significantly. In addition, they can be used effectively to plot routes (such as for a package delivery service).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000284

Normalization

Jan L. Harrington , in Relational Database Design (Third Edition), 2009

Translating an ER Diagram into Relations

An ER diagram in which all many-to-many relationships have been transformed into one-to-many relationships through the introduction of composite entities can be translated directly into a set of relations. To do so:

▪: Create one table for each entity.
▪: For each entity that is only at the "one" end of one or more relationships and not at the "many" end of any relationship, create a single-column primary key, using an arbitrary unique identifier if no natural primary key is available.
▪: For each entity that is at the "many" end of one or more relationships, include the primary key of each parent entity (those at the "one" end of the relationships) in the table as foreign keys.
▪: If an entity at the "many" end of one or more relationships has a natural primary key (for example, an order number or an invoice number), use that single column as the primary key. Otherwise, concatenate the primary key of its parent with any other column or columns needed for uniqueness to form the table's primary key.

Following these guidelines, we end up with the following tables for the Antique Opticals database:

Customer (customer_numb, customer_first_name, customer_last_name, customer_street, customer_city, customer_state, customer_zip, customer_phone)

Distributor (distributor_numb, distributor_name, distributor_street, distributor_city, distributor_state, distributor_zip, distributor_phone, distributor_contact_person, contact_person_ext)

Item (item_numb, item_type, title, distributor_numb, retail_price, release_date, genre, quant_in_stock)

Order (order_numb, customer_numb, order_date, credit_card_numb, credit_card_exp_date, order_complete?, pickup_or_ship?)

Order item (order_numb, item_numb, quantity, discount_percent, selling_price, line_cost, shipped?, shipping_date)

Purchase (purchase_date, customer_numb, items_received?, customer_paid?)

Purchase item (purchase_date, customer_numb, item_numb, condition, price_paid)

Actor (actor_numb, actor_name)

Performance (actor_numb, item_numb, role)

Producer (producer_name, studio)

Production (producer_name,item_numb)

Note: You will see these relations reworked a bit throughout the remainder of the first part of this book to help illustrate various aspects of database design. However, the preceding is the design that results from a direct translation of the ER diagram.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123747303000061

Normalization

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

Translating an ER Diagram into Relations

An ER diagram in which all many-to-many relationships have been transformed into one-to-many relationships, through the introduction of composite entities, can be translated directly into a set of relations. To do so:

■: Create one table for each entity.
■: For each entity that is only at the "one" end of one or more relationships, and not at the "many" end of any relationship, create a single-column primary key, using an arbitrary unique identifier if no natural primary key is available.
■: For each entity that is at the "many" end of one or more relationships, include the primary key of each parent entity (those at the "one" end of the relationships) in the table as foreign keys.
■: If an entity at the "many" end of one or more relationships has a natural primary key (for example, an order number or an invoice number), use that single column as the primary key. Otherwise, concatenate the primary key of its parent with any other column or columns needed for uniqueness to form the table's primary key.

Following these guidelines, we end up with the following tables for the Antique Opticals database:

Note: You will see these relations reworked a bit throughout the remainder of the first part of this book to help illustrate various aspects of database design. However, the preceding is the design that results from a direct translation of the ER diagram.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000077

Database Design Case Study #1: Mighty-Mite Motors

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

The ER Diagram

The systems analyst preparing the requirements document for the Mighty-Mite Motors reengineering project has had two very good sources of information about exactly what needs to be stored in the database: the employees of the company and the paper documents that the company has been using. The document that is given to the database designer is therefore quite complete.

The design needs to capture all the information on the paper documents. Some documents are used only for input (for example, the product registration form or the order form). Others represent reports that an application program must be able to generate (for example, the line schedule report). Although the current documents do not necessarily represent all the outputs application programs running against the database will eventually prepare, they do provide a good starting place for the design. Whenever the designer has questions, he or she can then turn to Might-Mite's employees for clarification.

Working from the requirements document prepared by the systems analyst, along with the paper input and output documents, the database designer puts together the ER diagram. Because there are so many entities, all of which interconnect, the diagram is very wide. It has therefore been split into three pieces so you can see it. As you look at each piece, keep in mind that entities that appear on more than one piece represent the connection between the three illustrations.

The first part (found in Figure 13.13) contains the entities for raw materials and manufacturing. This portion of the data model is dealing with three many-to-many relationships:

▪: material_order to raw_material (resolved by the composite entity material_order_line),
▪: raw_material to model (resolved by the composite entity material_needed),
▪: manufacturing_line to model (resolved by the composite entity line_schedule).

The second portion of the ERD (Figure 13.14) contains entities for product testing and sales. (Remember that in this instance, the customers are toy stores rather than individual purchasers.) There are two many-to-many relationships:

▪: test_type to model (resolved by the test entity),
▪: order to model (resolved by the order_line composite entity).

The test entity is somewhat unusual for a composite entity. It is an activity that someone performs and, as such, has an existence outside the database. It is not an entity created just to resolve a many-to-many relationship.

At this point, the diagrams become a bit unusual because of the need to keep track of individual products rather than simply groups of products of the same model. The model entity, which you first saw in Figure 13.13, represents a type of vehicle manufactured by Mighty-Mite Motors. However, the product entity, which first appears in Figure 13.14, represents a single vehicle that is uniquely identified by a serial number. This means that the relationships between an order, the line items on an order, and the models and products are more complex than for most other sales database designs.

The order and line_item entities are fairly typical. They indicate how many of a given model are required to fill a given order. The shipment entity then indicates how many of a specific model are shipped on a specific date. However, the database must also track the order in which individual products are shipped. As a result, there is a direct relationship between the product entity and the order entity in addition to the relationships between order_line and model. In this way, Mighty-Mite Motors will know exactly where each product has gone. At the same time, the company will be able to track the status of orders (in particular, how many units of each model have yet to ship).

The final portion of the ERD (Figure 13.15) deals with the purchasers and problem reports. There are two many-to-many relationships:

▪: problem_type to product (resolved with the entity problem_report),
▪: purchase to feature (resolved with the composite entity purchase_feature).

As with the test entity that you saw earlier, the problem_report entity acts like a composite entity to resolve a many-to-many relationship, but is really a simple entity. It is an entity that has an existence outside the database and was not created simply to take care of the M:N relationship.

Note: Calling an entity "problem_report" can be a bit misleading. In this case, the word "report" does not refer to a piece of paper, but to the action of reporting a problem. A "problem_report" is therefore an activity rather than a document. In fact, the printed documentation of a problem report will probably include data from several entities, including the product, problem_report, purchase, and owner entities.

If you look closely at the diagram, you'll notice that there is a one-to-one relationship between the product and purchase entities. The handling of the data supplied by a purchaser on the product registration card presents an interesting dilemma for a database designer. Each product will be registered by only one purchaser. (Even if the product is later sold or given to someone else, the new owner will not have a registration card to send in.) There will be only one set of registration data for each product, at first thought suggesting that all the registration data should be part of the product entity.

However, there is a lot of registration data—including one repeating group (the features for which the purchaser chose the product, represented by the feature and purchase_feature entities)—and the product is involved in a number of relationships that have nothing to do with product registration. If the DBMS has to retrieve the registration data along with the rest of the product data, database performance will suffer. It therefore makes sense in this case to keep the purchase data separate and to retrieve it only when absolutely needed.

Note: One common mistake made by novice database designers is to create an entity called "registration card." It is important to remember that the card itself is merely an input document. What is crucial is the data the card contains and the entity that the data describe, rather than the medium on which the data are supplied.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000132

Database Design Case Study #2: East Coast Aquarium

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

The Animal Tracking Database

The animal tracking database is considerably bigger than the volunteers database. The application that will manipulate that database therefore is concomitantly larger, as demonstrated by the menu tree in Figure 14.20. (The File and Edit menus have been left off so the diagram will fit across the width of the page. However, they are intended to be the first and second menus from the left, respectively. A Help menu can also be added along the right side.)

The functionality requested by the animal handlers falls generally into four categories: the locations (the tanks) and their habitats, the species, the food, and the sources of animals. The organization of the application interface, therefore, was guided by those groups.

Highlights of the Application Prototype

The screen and report layouts designed for the animal tracking application provide a good starting place for the database designers to identify the entities and attributes needed in the database. As with the volunteers application, there is not necessarily a one-to-one correspondence between an entity and an output.

Note: One of the common mistakes made when designing the interface of database application programs is to use one data entry form per table. Users do not look at their environments in the same way as a database designer, however, and often the organization imposed by tables does not make sense to the users. Another benefit of prototyping is therefore that it forces database and application designers to adapt to what the users really need, rather than the other way around.

Food Management

One of the important functions mentioned by the aquarium's animal handlers was management of the aquarium feeding schedule (including what should be fed and what was fed), and the food inventory. First, they wanted a daily feeding schedule that could be printed and carried with them as they worked (for example, Figure 14.21). They also wanted to be able to record that feeding had occurred so that an updated feeding schedule could take prior feedings into account. Knowing that each species may eat more than one type of food and that each type of food can be eaten by many species, a database designer realizes that there are a number of entities required to implement what the users need:

■: An entity that describes each species.
■: An entity that describes each tank in the aquarium.
■: An entity that describes a type of food.
■: A composite entity between the species and location entities to record where a specific species can be found.
■: A composite entity between a species and a type of food, recording which food a species eats, how much it eats, and how often it is fed.
■: A composite entity between a species and a type of food, recording which food was fed to an animal, when it was fed, and how much it was fed.

Food inventory management—although it sounds like a separate application to the animal handlers—actually requires nothing more than the food entity. The food entity needs to store data about how much food is currently in stock (modified by data from the entity that describes what was fed and by manual entries made when shipments of food arrive) and a reorder point.

Handling Arriving Animals

When a shipment of animals arrives at the aquarium, animal handlers first check the contents of the shipment against the shipment's paperwork. They then take the animals and place them in the aquarium's quarantine area. The data entry form that the animal handlers will use to store data about arrivals therefore includes a place for entering an identifier for the tank in which the new animals have been placed (Figure 14.22). Given that the aquarium staff needs to be able to locate animals at any time, this suggests that the quarantine tanks should be handled no differently from the exhibit tanks and that there is only one entity for a tank.

After the quarantine period has expired and the animals are certified as healthy, they can be transferred to another location in the building. This means an application program must delete the species from their current tank (regardless of whether it is a quarantine tank or an exhibit tank) and insert data for the new tank. The screen form (Figure 14.23) therefore lets the user identify the species and its current location using popup menus. The user also uses a popup menu to identify the new location. To the database designer, this translates into the modification of one row (if the species is new to the exhibit tank) or the modification of one row and the deletion of another (if some of the species already live in the exhibit tank) in the table that represents the relationship between a species and a tank. All the database designer needs to do, however, is to provide the table; the application program will take care of managing the data modification.

Problem Analysis

The health of the animals in the aquarium is a primary concern of the animal handlers. They are therefore anxious to be able to analyze the problems that occur in the tanks for patterns. Perhaps a single species is experiencing more problems than any other; perhaps an animal handler is not paying as much attention to the condition of the tanks for which he or she is responsible.

The animal handlers want the information in Figure 14.24 included in the problem summary report. What cannot be seen from the summary screen created by the CASE tool is that the data will appear as a control-break layout. For example, each tank number will appear only once; each species will appear once for each tank in which it was the victim of a problem. By the same token, each type of problem will appear once for each tank and species it affected. Each type of problem also will appear once for each tank and species it affected. Only the problem solutions will contain data for every row in the sample output table.

To a database designer, the form in Figure 14.24 suggests the need for five entities:

■: The species.
■: The tank.
■: The type of problem.
■: A problem occurrence (a type of problem occurring in one tank and involving one species).
■: Problem solutions (one or more solutions tried for one problem occurrence). There may be many solutions to a single problem occurrence.

One of the best ways to handle problems is to avoid them. For this reason, the animal handlers also want to include maintenance data in their database. To move data entry simpler for the end users, the form for entering required maintenance (Figure 14.25) lets a user select a tank and then enter as many maintenance activities as needed.

A database designer views such a form as requiring three entities: the tank, the maintenance activity, and the maintenance required for this tank (a composite entity between the tank and maintenance activity entities).

Creating the ER Diagram

After refining the entire application prototype (and giving it a far more attractive design than the rather dull output produced by the CASE tool), the database designers for the East Coast Aquarium generate a large interconnected ER diagram. (Part I can be found in Figure 14.26; part II appears in Figure 14.27.) As you can see, when examining both diagrams, the centerpiece is the species entity, which participates in seven different relationships.

There are at least 11 many-to-many relationships represented by this design:

■: Species to location
■: Location to habitat
■: Species to habitat
■: Location to maintenance activity for required maintenance
■: Location to maintenance activity for maintenance performed
■: Location to problem
■: Species to problem
■: Species to food
■: Species to source for ability of source to supply the species
■: Shipment to species
■: Illness to individual animal for tracking the condition of mammals and other large animals

The relationships involving location, problem, and species are particularly interesting. On the surface, there appears to be a many-to-many relationship between a tank and a type of problem. By the same token, there appears to be another many-to-many relationship between a species and a type of problem. The problem is that if the database maintained the two separate relationships, each with its own individual composite entity, then it will be impossible to determine which species was affected by which problem, in which tank. To resolve the issue, the designer uses a three-way composite entity— problem_occurrence— that relates three parent entities (location, problem, and species) rather than the traditional two. Semantically, a problem occurrence is one type of problem affecting one species in one location and therefore identifying it in the database requires all three parent entities.

In contrast, why is there no three-way composite entity between species, location, and habitat? As with the preceding example, there is a many-to-many relationship between species and location, and a many-to-many relationship between habitat and location. The answer, once again, lies in the meaning of the relationships. Were we to create a single composite entity relating all three entities, we would be asserting that a given species lives in a given habitat, in a given location. However, the animal handlers at the aquarium know that this type of data is not valid, particularly because if an animal lives in a tank with many habitats, it may move among multiple habitats. Instead, the relationship between species and habitat indicates all habitats in which a species can live successfully; the relationship between location and habitat indicates the habitats present in a tank.

The remainder of the many-to-many relationships are the typical two-parent relationships that you have been seeing throughout this book. The only aspect of these relationships that is the least bit unusual is the two relationships between maintenance activity and location. Each relationship has a different meaning (scheduled maintenance versus maintenance actually performed). The design therefore must include two composite entities, one to represent the meaning of each individual relationship.

Note: There is no theoretical restriction to the number of relationships that can exist between the same parent entities. As long as each relationship has a different meaning, there is usually justification for including all of them in a database design.

Creating the Tables

The ER diagrams translate to the following tables:

Choosing a primary key for the problem_occurrence table presents a bit of a dilemma. Given that a problem occurrence represents a relationship between a problem type, tank, and species, the theoretically appropriate primary key is a concatenation of the problem type, tank number, species number, and problem date. However, this is an extremely awkward primary key to use as a foreign key in the problem_resolution table. Although it is unusual to give composite entities arbitrary unique keys, in this case it makes good practical sense.

There are several tables in this design that are "all key" (made up of nothing but the primary key). According to the CASE tool used to draw the ER diagram, this represents an error in the design. However, there is nothing in relational database theory that states that all-key relations are not allowed. In fact, they are rather common when they are needed to represent a many-to-many relationship that has no accompanying relationship data.

Generating the SQL

The SQL CREATE statements that generate the animal tracking database for East Coast Aquarium can be found in Figure 14.28. Because of the large number of composite entities, there are also a large number of foreign keys. Other than that, the SQL presents no unusual features.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000144

Database Design Case Study 2

Jan L. Harrington , in Relational Database Design (Third Edition), 2009

Highlights of the Application Prototype

The screen and report layouts designed for the animal tracking application provide a good starting place for the database designers to identify the entities and attributes needed in the database. As with the volunteers' application, there is not necessarily a one-to-one correspondence between an entity and an output.

Note: One common mistake made when designing the interface of database application programs is using one data entry form per table. Users do not look at their environments in the same way as a database designer, however, and often the organization imposed by tables does not make sense to the users. Another benefit of prototyping is therefore that it forces database and application designers to adapt to what the users really need, rather than the other way around.

Food Management

One of the important functions mentioned by the aquarium's animal handlers was management of the aquarium feeding schedule (including what should be fed and what was fed) and the food inventory. First, they wanted a daily feeding schedule that could be printed and carried with them as they worked (for example, Figure 12-21). They also wanted to be able to record when animals had been fed so that an updated feeding schedule could take prior feedings into account. Knowing that each species may eat more than one type of food and that each type of food can be eaten by many species, a database designer realizes that there are a number of entities required to implement what the users need:

▪: An entity that describes each species.
▪: An entity that describes each tank in the aquarium.
▪: An entity that describes a type of food.
▪: A composite entity between the species and location entities to record where a specific species can be found.
▪: A composite entity between a species and a type of food recording which food a species eats, how much it eats, and how often it is fed.
▪: A composite entity between a species and a type of food recording which food was fed to an animal, when it was fed, and how much of it was fed.

Although it sounds like a separate application to the animal handlers, food inventory management actually requires nothing more than the food entity. The food entity needs to store data about how much food is currently in stock (modified by data from the entity that describes what was fed and by manual entries made when shipments of food arrive) and a reorder point.

Handling Arriving Animals

When a shipment of animals arrives at the aquarium, animal handlers first check the contents of the shipment against the shipment's paperwork. They then take the animals and place them in the aquarium's quarantine area. The data entry form that the animal handlers will use to store data about arrivals therefore includes a place for entering an identifier for the tank in which the new animals have been placed (Figure 12-22). Given that the aquarium staff needs to be able to locate animals at any time, this suggests that the quarantine tanks should be handled no differently from the exhibit tanks and that there is only one entity for a tank.

After the quarantine period has expired and the animals are certified as healthy, they can be transferred to another location in the building. This means an application program must delete the species from their current tank (regardless of whether it is a quarantine tank or an exhibit tank) and insert data for the new tank. The screen form (Figure 12-23) therefore lets the user identify the species and its current location using pop-up menus. The user also uses a pop-up menu to identify the new location. To the database designer, this translates into the modification of one row (if the species is new to the exhibit tank) or the modification of one row and the deletion of another (if some of the species already live in the exhibit tank) in the table that represents the relationship between a species and a tank. All the database designer needs to do, however, is to provide the table; the application program will take care of managing the data modification.

Problem Analysis

Animal handlers are primarily concerned with the health of the animals in the aquarium. Therefore, it is important that they be able to detect any patterns while analyzing problems that occur in the tanks. Perhaps a single species is experiencing more problems than any other, or perhaps an animal handler is not paying as much attention to the condition of the tanks for which he or she is responsible.

The animal handlers want the information in Figure 12-24 included in the problem summary report. What cannot be seen from the summary screen created by the CASE tool is that the data will appear as a control-break layout. For example, each tank number will appear only once, and each type of animal will appear once for each tank in which it was the victim of a problem.

By the same token, each type of problem will appear once for each tank and species it affected. Only the problem solutions will contain data for every row in the sample output table.

To a database designer, the form in Figure 12-24 suggests the need for five entities:

▪: The species
▪: The tank
▪: The type of problem
▪: A problem occurrence (a type of problem occurring in one tank and involving one species)
▪: Problem solutions (one or more solutions tried for one problem occurrence). There may be many solutions to a single problem occurrence.

One of the best ways to handle problems is to prevent them in the first place. For this reason, the animal handlers also want to include maintenance data in their database.

To make data entry simpler for the end users, the form for entering required maintenance (Figure 12-25) lets a user select a tank and then enter as many maintenance activities as needed.

A database designer views such a form as requiring three entities: the tank, the maintenance activity, and the maintenance required for that tank (a composite entity between the tank and maintenance activity entities).

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123747303000140

Knowledge of system as an element of cybersecurity argument

Nikolai Mansourov , Djenana Campara , in System Assurance, 2011

4.1 What is system?

The word "system" became quite common in our everyday language to the extent that there is some confusion in its usage between different communities. Indeed, this word is used rather often, as we speak of "the solar system," "a system of government," "a health system," "a system of winning poker," a "communication system," or a "weapon system," and in so doing, we imply certain purposefulness and some sort of organization imposed on various elements that interact between themselves. A system is something that involves and exhibits behavior—a set of activities that can be defined in terms of the manipulation of materials, energy, or information.

A standard definition of a system by IEEE: System is a collection of components organized to accomplish a specific function or set of functions [IEEE 610.12].

Systems are studied by the general systems theory—an interdisciplinary theory about the nature of complex organizations in nature, society, and science, and is a framework by which one can investigate and/or describe any group of elements that are functioning together to fulfill some objective (whether intended, designed, man made, or not).

A standard definition of a system from the systems engineering community: A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific production, support, or mission requirement. [ Air Force 2000]

On the other hand, certain communities prefer to use the word "system" in its narrow and concrete meaning—such as a particular computer application, or a physical system, a facility with a specific geographic location that involves a certain technology to provide service. Concrete systems are procured by organizations and fielded to support organizations and their operations [DoDAF 2007]. The context in which a concrete technical system operates is referred to as an "organization," which is defined as "an organization structure with a mission." In a business community, the term "enterprise" is often used to refer to the complex socio-technical organizations designed to provide goods and services to their customers.

National Institute for Standards and Technology (NIST) equates "system" and "information system" [NIST SP 800-18] and defines "information system" as a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Certain communities prefer to use the term "network," or "organization network" to mean a specific installation of personnel, operational procedures, technology, and physical facilities, that contain valuable information assets of the organization, in particular, the Network Rating Methodology from the National Security Agency (NSA) [Moore 2000].

The Information Technology Security community distinguishes a system, which is defined as a specific installation "with particular purpose and a known operational environment" and a product, which is defined as "a hardware and/or software package that can be bought off the shelf and incorporated into a variety of systems" [ISO 15408].

System assurance deals with man-made systems, created and utilized for the benefit of man. Cyber systems involve a combination of hardware, software, and humans. System assurance embraces the entire system life cycle from the conception of ideas through to the retirement of a system. System assurance supports the governance of systems and the processes for acquiring and supplying system products and services. Reasoning about systems for the purpose of evaluating security posture requires a common vocabulary that can be used to improve communication and cooperation between diverse disciplines and identify, utilize and manage relevant information units in an integrated, coherent fashion.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978012381414200004X

Binding Problem, Neural Basis of

C. von der Malsburg , in International Encyclopedia of the Social & Behavioral Sciences, 2001

1 The Binding Problem

One of the solid results of research on brain function is the localization of mental themes in the brain in a hierarchical manner down to the assignment of definite semantic meaning to individual neurons. It is, therefore, a broadly accepted view that neurons can be treated as elementary symbols with fairly fixed meaning. The assignment of meaning to neurons has been a very successful enterprise for decades, and it is probably a permissible extrapolation to apply this picture to every neuron in our cerebrum, if not in our whole nervous system. It has, furthermore, long been an uncontested view that the state of a neuron can be characterized by an activity variable, which in a not very precisely definable way corresponds to its current rate of firing (one speaks of 'rate coding'). Semantic meaning is routinely assigned to neurons by temporally associating their rate of firing with sensory stimuli or motor responses.

A neuron is thus taken as an elementary symbol that is either active or dormant in a given mental state. It is elementary in the sense of having no internal structure in terms of subsymbols (although a neuron's semantic referent invariably is a composite entity). As a rule there seem to be groups of equisemantic neurons. To allow for this possibility, the term 'single unit' will be used instead of 'single neuron.' In spite of all the internal anatomical and physiological structure of single units, the mental symbols associated with them are taken to be elementary, i.e., as having no internal degrees of freedom.

At issue here are the laws by which higher symbols are composed from single units. With rate coding there is only one composition rule: mere additive, unstructured combination of the active units' elementary meanings into one amorphous lump. This is a very poor composition rule, and a somewhat inadequate basis for cognitive and mental operations. A few examples may illustrate this inadequacy. Assume a first mental object (e.g., an imagined hand) to be represented by the set A of single units, and a second mental object (e.g., an apple) by set B (for simplicity let A and B have no units in common). Now assume there is reason to hold both mental objects simultaneously (as, for instance, when the hand is grasping the apple). The above composition rule states that the superset $C = A \cup B$ will be active. This, however, creates a problem in that C doesn't contain any information as to grouping of its elements in terms of its constituents A and B, and there now may be several ways to decompose C into part symbols. This ambiguity has been termed the 'superposition catastrophe.' In a more concrete example, let a person perceive a blue letter A and a yellow letter B on a sheet of paper, and assume there are units to represent 'A,' 'B,' 'blue' and 'yellow' in the person's brain. The simultaneous activity of all four units represents the situation incompletely, as a yellow A and a blue B would evoke the same situation. This type of 'conjunction errors' are actually committed by human subjects when not given enough time to inspect a situation (for review see Wolfe and Cave 1999). The experimental examples show that the binding of elements into groups can be a real problem for our brain if it is not given sufficient time.

If single units are the mind's 'bricks,' what is the 'mortar' to erect its cognitive edifices—to group features into objects (such as in figure–ground separation), to attach attributes to referents (such as grammatical roles to the words of a sentence), to represent temporal or spatial arrangements of elements such as in a spoken sentence or in a visual scene, or to point out correspondences between structures found to be analogous to each other?

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B008043076703655X

Object-Relational Databases

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

ER Diagrams for Object-Relational Designs

The Information Engineering, or IE, type of ER diagram does not lend itself to the inclusion of objects because it has no way to represent a class. Therefore, when we add objects to a relational database, we have to use another ERD style.

Although there are many techniques for object-oriented ERDs, one of the most commonly used is the Unified Modeling Language (UML). When used to depict a post-relational database design, UML looks a great deal like the IE style, but indicates relationships in a different way.

An example of an ER diagram using UML can be found in Figure 27.14. This design is of a purely object-oriented database and includes some elements that therefore won't appear in a hybrid design. It has been included here to give you an overview of UML so that you can better understand the portions of the modeling tool that we will be using later in this chapter.

The basic features of UML include the following:

■: A regular class is represented by a rectangle, divided into three parts (name, attributes, procedures).
■: An aggregate class (a metaclass in the diagram)—a class that collects all objects of a given class—is represented by a rectangle containing its name and the rectangles of the classes whose objects it aggregates. For example, in Figure 27.14, the Product and Source classes are within their aggregate classes, AllProducts and AllSources, respectively.
■: Relationships between entities are shown with lines with plain ends. The cardinality of a relationship is represented as n, n..n, or n..*. For example, if the cardinality is 1, it is simply written as 1. If the cardinality is 0 or more, it appears as 0..*; 1 or more appears as 1..*. Notice in Figure 27.14 that there are several direct many-to-many relationships, shown with 0..* at either end of the association line.
■: Inheritance is shown by a line with an open arrow pointing toward the base class. In Figure 27.14, the Footwear and Headgear classes have such arrows pointing toward Product.
■: What we call composite entities in a relational database are known as association classes. They are connected to the relationship to which they apply with a dashed line. As you can see in Figure 27.14, the MaterialSupplied and MaterialUse classes are each connected to at least one many-to-many relationship by the required dashed line.

In addition to the basic features shown in Figure 27.14, UML diagrams can include any of the following:

■

An attribute can include information about its visibility (public, protected, or private), data type, default value, and domain. In Figure 27.15, for example, you can see four classes and the data types of their attributes. Keep in mind that, in an object-oriented environment, data types can be other classes. Therefore, the Source class uses an object of the TelephoneNumber class for its phoneNumber attribute, and an object of the Address class for its sourceAddress attribute. In turn, Source, Address, and TelphoneNumber all contain attributes that are objects of the String class.

■

Procedures (officially called operations by UML) can include their complete program signature and return data type. If you look at Figure 27.15, for example, you can see each operation's name followed by the type of data it requires to perform its job (parameters). Together, the procedure's name and parameters make up the procedure's signature. If data are returned by the operation, then the operation's signature is followed by a colon and the data type of the return value, which may be an object of another class or a simple data type such as an integer.

■

Solid arrows can be used at the end of associations to indicate the direction in which a relationship can be navigated.

Note: Pure object-oriented databases are navigational, meaning that traversal through the database is limited to following predefined relationships. Because of this characteristic, some theorists feel that the object-oriented data model is a step backwards rather than forward and that the relational data model continues to have significant advantages over any navigational data model.

There are three possible ways to use the arrows:

❏: Use arrows on the ends of all associations where navigation is possible. If an association has a plain end, then navigation is not possible in that direction. This would indicate, for example, a relationship between two objects that is not an inverse relationship, where only one of the two objects in a relationship contains the object identifier of a related object.
❏: Show no arrows at all, as was done in Figure 27.15. In that case, the diagram provides no information about how the database can be navigated.
❏: Show no arrows on associations that can be navigated in both directions, but use arrows on associations that can be navigated in only one direction. The drawback to this approach is that you cannot differentiate associations that can be navigated in both directions from associations that cannot be navigated at all.

■

An association that ends in a filled diamond indicates a whole–part relationship. For example, if you were representing a spreadsheet in a database, the relationship between the spreadsheet and its cells could be diagrammed as in Figure 27.16. The filled diamond can also be used to show aggregation, instead of placing one object within another, as was done in Figure 27.14.

■

When an association is between more than two objects, UML uses a diamond to represent the relationship. If an association is present, it will be connected to the diamond, as in Figure 27.17. The four classes in the illustration represent entities from a poetry reading society's database. A "reading" occurs when a single person reads a single poem that was written by one or more poets. The association entity indicates when and where the reading took place.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000272

Source: https://www.sciencedirect.com/topics/computer-science/composite-entity

Posted by: linseylinseysalmonse0288363.blogspot.com

Linsey Salmons

Widget HTML Atas

How To Represent Composite Attribute In Er Diagram

Composite Entity

Entities and Relationships

Composite Entities

Relational Databases and "Big Data": The Alternative of a NoSQL Solution

Graph

Normalization

Translating an ER Diagram into Relations

Normalization

Translating an ER Diagram into Relations

Database Design Case Study #1: Mighty-Mite Motors

The ER Diagram

Database Design Case Study #2: East Coast Aquarium

The Animal Tracking Database

Highlights of the Application Prototype

Food Management

Handling Arriving Animals

Problem Analysis

Creating the ER Diagram

Creating the Tables

Generating the SQL

Database Design Case Study 2

Highlights of the Application Prototype

Food Management

Handling Arriving Animals

Problem Analysis

Knowledge of system as an element of cybersecurity argument

4.1 What is system?

Binding Problem, Neural Basis of

1 The Binding Problem

Object-Relational Databases

ER Diagrams for Object-Relational Designs