Data Modeling for Database Design in Production and Health

Data Modeling for Database Design in Production and Health Monitoring Systems for Dairy Herds FRANGOISE LESCOURRET, M. GENEST, J. BARNOUIN, MICHELLE CHASSAGNE, and 8. FAYE

Laboratoire d’Ecopathologie lnstitut National de la Recherche Agronomique Centre de Clermont-Ferrand-Theix 63122 Saint Genes Charnpanelle, France ABSTRACT

Monitoring systems, increasingly used in dairy herds, require carefully designed databases. Database design involves modeling, which is generally not treated in papers dealing with such monitoring systems. We present general rules of data modeling based on the analysis of the semantic structure of information and their application to the construction of five basic data models. Such models are not database structures; a single model can be translated into different database structures. Modeling choices related to utilization requirements are explained. The models provide a sound basis for database schemes that prevent redundancy and support various applications in production and health monitoring systems for dairy herds and refer to information sets at either the cow or the farm level, including unique life history features, individual morbidity, production and reproduction performance, herd management systems, and feeding practices. The efficiency of the models is illustrated by their contribution to a real database; emphasis is on their integration into a model, on the ease of translation into relational database tables, and on subsequent database performance. (Key words: dairy herds, database design, monitoring systems) INTRODUCTION

Monitoring systems are increasingly used in dairy herds for management, performance evaluation, and research (6, 11, 14, 17). These

Received August 19, 1992. Accepted November 17, 1992. 1993 J Dairy Sci 76:1053-1062

systems require carefully designed computerized databases to provide both flexible and rapid access to data and rational use of disk space and memory (21). Before implementation on the computer, database design should include three steps: identification of data items to be recorded, based on future expected use of the items; data modeling; and translation of the data model into a database scheme (15). Data modeling, which is used to represent the intricate structure of information, is not discussed in most papers that present information systems in biological journals except for broiler production (12) or for small animal clinical diseases (18) although modeling provides a sound basis for database schemes that prevent redundancy, support easy entry and retrieval of information, and accommodate new and unexpected items of information (8). To our knowledge, no data model of information systems for monitoring health or production in dairy herds has been published except that of Lescourret et al. (10). Our paper presents the main principles of data modeling and their application to the construction of five basic data models. These models, which are as universal as possible, are basic patterns intended for a large range of databases related to production and health monitoring systems for dairy herds. Each model is related to an information set at either the cow or the farm level. The first set involves unique life history features of cows, containing identification, genealogy, and culling. The two following sets contain data collected during the course of the cow’s life, individual morbidity (e.g., mastitis and lameness,), and production and reproduction performance @e., milk production, milk composition, bacteriological quality of milk, drying off, calving, and services). The last two sets contain data on herd management systems and on feeding practices.

1053

1054

LESCOURRET ET AL.

The efficiency of the models will be illustrated by their contribution to a real database; emphasis is on ease of integration into a data model, on the facility of translation into relational database tables (the present standard), and on subsequent database performances.

some entities and relationships are obvious, as in the examples just given, the definition of items from the real world as entities, relationships, or attributes often depends on the utilization of information (13). Recorded values give real existence to attributes, entities, and relationships. Thus, monitored cows are occurrences of the entity MATERIALS AND METHODS “cow”. Entities are specified through a discriminative set of attributes for which each Deflnltions and General Prlnclpler Occurrence has a different value (e.g., identifiof Data Modeling cation number for the entity “cow”). This set is The real system about which information is called the identifier. The identifier of a relato be stored in a database is composed of basic tionship is composed of the identifiers of the data items (e.g., cow breed, cow birth date, and related entities (e.g., cow number plus farm farm serial number) organized in a complex code for the relationship “cow-farm”). way. At this level, the semantic structure of the Information about the minimum and maxiinformation is relevant (9); analysis of this mum number of occurrences of each entity that semantic structure results in a data model that is allowed in a relationship is indicated by can accommodate all of the data required for specifying (O,l), (O,N), (l,l), or (1,N) where N record keeping and provide the foundation for indicates any number 22. These numbers are various functions (8). This model is called a called cardinalities. For example, “each cow conceptual model because the analysis is at a may belong to one farm only (one farm at the conceptual level; i.e., it is free of the con- minimum and one farm at the maximum) in straints of database management system im- the studied system” is depicted by a cardinality plementation. A conceptual model is not a of 1,l of the relationship “cow-farm” for database structure, because a single model can “cow”. In the same way, because each farm be translated into different data structures (hi- may manage one cow at the minimum and erarchical, relational, or networking) (9). The several cows at the maximum, the cardinality conceptual modeling guidelines of MERISE of “cow-farm” for “farm” is 1,N. Cardinalities (9), which is widely used to design and to are crucial for depicting reality and for transimplement databases in France, are presented. lating the conceptual model into a database Most methods used to analyze the semantic structure. Optimization of the conceptual data model structure of information are based on the “entity-relationship” approach (3), which con- by checking the assignment of attributes, siders that the real world consists of entities reducing redundancy, and decomposing relaand relationships; entities are classes of real tionships in fewer n-ary relationships is imporobjects (cow, farm) or abstract objects (dis- tant for a reliable representation of reality and ease), and relationships are connections be- future database performance (13). This optimitween two or more entities (e.g., cows belong zation is obtained by the verification of two to farms). Conceptual data modeling consists rules by Codd’s techniques (4, 5 ) . 1) Each of identifying entities and relationships in the occurrence of each entity or relationship must data and allocating basic data items among have only one value for each of its attributes entities and relationships. For example, to de- (lactation number is not an attribute of “cow” fine the characteristics of entities and relation- because a cow can have several values for ships, cow breed and cow birth date are lactation number). 2) Each attribute of a relacharacteristics, also called attributes, of the tionship (except identifiers) must depend on entity “cow”, whereas period (during which a the entire relationship, not on a subset of the cow belongs to a farm) is an attribute of the relationship (a birth date cannot be assigned, relationship “cow-farm” that links “cow” and which is an attribute of “cow”, to the relation“farm”. A relationship connecting n entities is ship “cow-fapn”). Moreover, to depict correctly the studied called an “n-ary” relationship. A relationship may or may not contain attributes. Although system, an optional modeling rule can be used Journal of Dairy Science Vol. 76, No. 4, 1993

MODELING FOR DAIRY HERD DATABASE DESIGN

that forces any attribute of either an entity or a relationship to have a value for every occurrence. This rule causes entities or relationships to be split: attributes that may be lacking in an entity a or a relationship b are stored as a relationship (0,l) (case a) or (0,N) (case b), as opposed to being stored with the entity a or the relationship b. Examples are given in the description of models. Entities and relationships are represented pictorally through boxes and lines between boxes. Cardinalities and identifiers may be added to the scheme. Details on the principles of data modeling are described by Lescourret et al. (10). RESULTS AND DISCUSSION Application of the Principles to the Construction of Basic Conceptual Data Models

Assumptions are that farms are monitored during a period of time and that a monitored cow cannot belong to more than one monitored farm during this period. The first three models are at the cow level and the last two ones at the farm level. Unique Life History Features. The model is represented in Figure la. Among attributes that have only one value for the whole life history of any cow, some may have a value for all monitored cows, i.e., identification (cow number), birth date and breed, and sire or dam numbers (assumed to be sufficient genealogy descriptors). In this case, the attributes belong to the entity “cow”, for which the identifier is the cow number. Some cows may enter a monitored farm when purchased. Cows may leave a farm dead, sold, or culled for various reasons. Purchase date is laclung for cows born in the monitored farm to which they belong, and exit date, type (death, sale, or cull), and cause (e.g., low fertility, poor milk production, or disease) are lacking for cows in the herd at the end of the monitoring period. If we adopt the modeling rule that allows no entity attribute to have null values, purchase and exit dates cannot be represented as attributes of “cow”. Thus, an entity “date” is needed that consists only of an identifier to represent purchase and exit dates by relationships between r r ~ and ~ ~ “date”. ” (The minimum cardinality of the relationships for “date” is 0: any purchase date may not also

1055

be an exit date and vice versa.) Similarly, exit type and cause are depicted through a relationship between “COW” and an entity “exit” composed of exit type plus exit cause. The minimum cardinality of the relationship for “exit” may be 0 or 1, depending on whether the Occurrences of the entity are predefined combinations of exit types and causes or only those Occurrences observed during the monitoring period. The splitting of exit featuresAate, on the one hand, and type and cause, on the other hand-is an option (exit date could be put into “exit” as a part of the identifiers). The splitting introduces a consistency constraint; i.e., any cow with an exit date (an exit type and cause, respectively) must have an exit type and cause (an exit date, respectively). The maximum cardinalities of N of the relationships “exits” for “date” or “exit” mean that some dates (some combinations of exit types and causes) may relate to several cows. Routine Collection of Morbidity. The model is represented in Figure lb. Each cow may suffer from one or several diseases at any date. This rule is modeled by the 3-ary (entities, n = 3) relationship “suffers”, which links the entities “cow” and “date”, and an entity “disease” identified by a code. To remember the meaning of the codes easily when using the database, the user should associate a word or words with each code; e.g., as an attribute of the entity “disease”, ulcerative mastitis is associated with code UMA. The 0,N cardinalities of “suffers” for “COW” mean that any monitored cow may have been healthy during the entire monitoring period or may have been affected by several diseases. Applications of the future database may include retrievals of disease events per category, where category refers, for instance, to the nature of the disease or to the affected function: the category of all udder diseases may be U (for udder); it may be useful to construct a relationship “refers to” between “disease” and a new entity “category” on the same pattern as “disease” (code plus wording). The cardinality pattern of “refers to” (1,l for “disease”; 1,N for “category”) is typical of such hierarchical relationships. Production and Reproduction Performance. The model is represented in Figure IC. An individual lactation is the unit of analysis in many investigations. The future database perJournal of Dairy Science Vol. 76, No. 4, 1993

1056

LESCOURRET ET AL.

U& disease U

Figure 1 . Conceptual data models for cows: unique life history features (a), morbidity (b), and production and reproduction performance (c).

formances depend on the consideration of this fact in the data model. Thus, cow measures at the lactation level can be depicted as much as possible through relationships between “cow” and an entity “lactation number” with maximum cardinalities of N for each entity, enabling each cow to have completed several lactations during the monitoring period and enabling each lactation number (1,2,3. . .) to relate to several cows. The entity “lactation number” is made up of an identifier (lactation number). Measures at the lactation level were distributed into three relationships describing start of lactations (date), milk production, (milk, mean fat, and protein contents), and drying off (date, drug used for drying off), instead of being represented in a unique relationship, according to the rule related to possibly lacking Journal of Dairy Science Vol. 76. No. 4, 1993

values: drying off may be lacking for lactations stopped by culling. Recording calf features (sex and birth weight) is a current practice. This practice is depicted by a 3-ary relationship that contains calf features and links “cow”, “lactation number”, and another entity, “calf number”. The latter contains a serial number (i.e., numbers 1, 2, or 3) to distinguish a calf among twins or triplets. Services can occur more than once per lactation, so they are depicted by a binary relationship between “cow” and “date”. The number of the service sire, if known, may be an attribute of the relationship. If other sire characteristics are to be recorded, they should be included in an entity “sire” identified by the sire number and then services should be represented by a 3-ary relationship between “cow”, “date”, and “sire”.

MODELING FOR DAIRY HERD DATABASE DESIGN

year YaE

common practices

+

farm

1057

b

answers response

attributes Ly

ldentlller

0,N

cardlnallty

4

sense for u&rsrandlng the name 01 the relatknsh~o

I

Figure 2. Conceptual data models for farms: herd management system (a), and feeding practices (b). Optional attributes are shown in parentheses.

Microorganisms in milk samples can be recorded once or several times per lactation. Any analyzed milk sample may be free of any microorganism or contain one or more types of microorganisms. This fact is represented by a 3-ary relationship linking “cow”, “date”, and the entity “milk microorganism”; the relationship has the pattern described earlier for morbidity, but “milk microorganism” replaces “disease”. Characterization of Herd Management Systems. The model is represented in Figure 2a. Data on herd management systems (e.g., housing) are currently collected regularly (e.g., yearly) on a questionnaire completed by the dairy farmer. Every questioned dairy farm is an Occurrence of the entity “farm”; the latter is identified by a code (name or serial number). Some questions can be answered by all of the dairy farmers. Responses to such questions

are attributes of a binary relationship “common practices” between “farm” and an entity “year”. Other questions are likely to be less relevant for some dairy farmers (e.g., a question on the modalities of tie-stall housing does not concern farms with loose housing). The replies to such questions are represented through a 3-ary relationship “answers” between “farm”, “year”, and another entity “special practice”, which is identified by a code refemng to a particular question. Feeding Practices. The model is represented in Figure 2b. The way of modeling the supply of elements (feeds or minerals) depends on the nature and use of information. For example, feedstuff supply occurs during a specific period for each feedstuff. However, various feedstuffs are generally supplied simultaneously, and the periods during which feed composition or quantity does not change Journal of Dairy Science Vol. 76. No. 4. 1993

1058

LESCOURRET ET AL.

may be needed during data processing. These periods may be difficult to calculate at processing time, so they may be needed in the conceptual data model. However, concerning mineral supply, periods during which no change in chemical composition or supplied quantity occurred may not be needed in the model, because these changes may be less frequent. Thus, only periods concerning the supply of individual mineral supplements may be useful to consider. These modeling choices are illustrated herein. (Opposite or similar choices would have been possible for feedstuffs and mineral supplements.) In dairy herds, a specific diet is generally supplied to each group of cows according to their physiological status, for instance, milking cows and dry cows. Linking of individual cows to groups is not of interest in our model. A diet is composed of variable feedstuffs, with a mean quantity per day for each, so that the

diet changes either when a feedstuff is added or removed or when a quantity is changed. Thus, a diet is identified by a farm, the group of cows to which it is supplied, and the period during which feed composition or quantity does not change. In the model, the diet is displayed as an entity in order to associate, through a binary relationship, each diet with the feedstuffs of which it is composed. The entity “diet” is linked to the entities “farm”, “group”, and “time period” by binary relationships that maintain the hierarchical pattern. The relationship “is composed”, which has the attribute “mean quantity per day and per cow”, links “diet” to “feedstuff”, which is identified by a code. The model could be improved if nutritive values (attributes of “feedstuff ’) are available. Similarly, mineral supplementation frequently is specific to cow groups. A mineral supplement is defined by its chemical compo-

I

herd management system

I

1

unique life history features

1

body scores cleanliness of cows

I

housing/pasture

farm

cow

i housing/mi I k ing practices

production/ reproduction drink water

, hematological / biochemical parameters

cow submodels

feeding practices

(pz---) microclimate

farm submodels

Figure 3. Integration of the conceptual data models (framed boxes) with specific submodels (octagonal boxes) into the global model of an epidemiological survey on dairy cows. Journal of Dairy Science Vol. 76. No. 4, 1993

MODELING FOR DAIRY HERD DATABASE DESIGN

sition and is given to each group during a particular period. A variety of mineral supplements may be given during the same period. The supply can be modeled by a 4-ary relationship between the entities “farm”, “time period”, “group”, and “mineral supplement”. The relationship contains the mean quantity per cow and per day. Efficiency of the Basic Conceptual Data Models

An Easy Integration into the Model of a Real Monitoring System. The previous basic models were integrated into the model of a monitoring system that supports a research program. This program relates to an epidemiological prospective 4-yr survey, which analyzes the occurrence of diseases,especially in

1059

the periparturient period, in dairy cows in the primary French dairy basin (Brittany region). Diseases are related to performance (such as reproduction features, milk production, milk composition, and bacteriological quality of milk). The risk factors are individual features (such as behavior, cleanliness of the cow, body condition scores, and hematological and biochemical parameters) and features related to herd management (diet, prophylactic practices, housing and milking practices, housing and pasture periods, drinking water quality, and climate) (7). The models presented were slightly changed to make them more specific. Their integration modified the cardinality patterns (e.g., a unique entity “date” was used for all of the dates of the survey so that minimum cardinalities of

TABLE 1. Translation of parts of the models into relational database tables.

Table

origin in the conceptual data models

“cow”

Entity “cow”

Relationships “belongs to” “is bought” “exits (1st)’’ “exits (2nd)” “cow disease”

Relationship “suffers”

“lactation”

Relationship “starts lactation”

“farm” “yearly” “practice”

Entity “farm” Relationships “common practices” “answed’

List of columns Cow number’ Breed Birth date Sire number Dam number Farm code2 Purchase date Exit date type cause Cow number plus disease code plus disease date Lactation number3 Cow number plus lactation number Starting date - (other columns)

-

Farm code Farm code plus Year PI4 on

lRimary key, identifies thc record. 2Foreign key = primary key in another table (useful for access to other tables). 3Redundancy added to facilitate the queries. 4Response to a question on a c m n t practice.

Journal of Dairy Science Vol. 76, No. 4, 1993

1060

LESCOURRET ET AL.

relationships for “date” were 0). Other specific submodels were established. The models relating to the cow or the farm level were combined by their common entity, “cow” (“farm”). The entity “COW” was linked to “farm” by a relationship that maintains the simple hierarchical pattern; i.e., each cow belonged to only one farm throughout the survey (Figure 3). The following examples were obtained from this application. Facility of Translation into Relational Database Tables. The translation is easy and rapid, according to a few standard guidelines. Conceptual entities become tables. Conceptual relationships for which all of the maximum cardinalities are N also become tables (Table 1). Other conceptual relationships are represented by the appearance of the same data item in the tables for the entities involved. These common attributes serve as links. For example, the “cow” table has a column designated farm code, which allows an implicit link to be drawn between an individual cow and the farm to which it belongs (Table 1). The conversion of a good conceptual model results in a database structure that is free of useless redundancies without useless splitting of information. Links between data are clear and simple so that two data items that are semantically distinct may be easily associated. Each table contains a number of records that represent all of the data about one occurrence of either the entity or the relationship from which it is derived; each column of the table contains values of one particular attribute of the entity (relationship). A few columns may be added to the tables; these columns, which could have been retrieved otherwise (through links between data), are redundancies that facilitate the access of users to information (Table 1). This addition may seem to be inconsistent with a careful avoidance of redundancy during conceptual modeling, but the addition is done with a full knowledge of facts; hence, update problems can be controlled. Subsequent Database Peflormances. A database derived from a good conceptual model guarantees data consistency to the users; most consistency constraints are included in the conceptual model. For example, the pattern of the table “cow” derived from the conceptual entity “cow” (Table 1) guarantees the uniqueness of certain attributes for productive life. Journal of Dairy Science Vol. 76, No. 4, 1993

Retrieval performance is the most spectacular feature. In the relational context, records are accessed through the language of a relational database management system, which allows retrieval from more than one table simultaneously when matching values occur in common columns. Examples of retrievals from the database (indexed) tables of Table 1 may be given; execution times are related to the relational database management system ORACLE (ORACLE Corp., Redwood Shores, CA) and a SUN 4390 computer (SUN Microsystems Inc., Mountain View, CA) operating on the UNIX system (UNIX Systems Laboratories, Summit, NJ): 1 s for providing the total number of cows per breed and farm recorded in the survey, from the table “cow” (4123 records); 15 s for displaying the lactations started in 1987 during which mastitis occurred, from the tables “cow disease” (13,957 records) and ‘‘lactation’’ (8938 records); and about 35 s for displaying simultaneously the identification numbers of cows still in the herd in 1987 (from the table “cow”), a binary variable indicative of disease occurrence for each cow during this year (from the table “COW disease”), and for displaying the responses concerning their herds in 1987 to some questions about the management system (from the table “yearly practice”, 188 records). The writing of these three retrievals is detailed in the Appendix. CONCLUSIONS

These conceptual data models contribute to development of a standard record format for livestock monitoring systems (16, 20). These models constitute a basic pattern for the design of database structures for dairy herds that can be easily queried. This pattern has to be fitted to specific needs because new data, new links between data, and new utilization requirements may occur. The construction principles presented and illustrated in this paper may constitute a basis for such improvements. The general design of information systems is another important area in which conceptual data models are relevant. To allow the construction of data models, future users of the information system are constrained to agree on what it is expected to do. As a consequence, useful feedback on important methodological

MODELING FOR DAIRY HERD DATABASE DESIGN

choices (objectives, data, and utilization of data) may occur because of conceptual modeling. Generally, models often form a framework for discussion or a tool for cognition (1, 2). Finally, conceptual data models are global pictures of the contents, the constraints, and the state of a real system, so they can be useful even after the implementation of the database; Le., these models can help the user in need of a minimal mastery of the system to formulate relevant queries. ACKNOWLEDGMENTS

The authors thank Michel Gtnard for helpful comments on the first drafts of the paper and Kirsten Rtrat for improving the English. REFERENCES 1 Armstrong. J. S. 1969. Modelling a grazing system.

Proc. Ecol. Soc. Aust. 6:194. 2 Attonaty, J. M., M. H. Chatelin. and J. C. Poussin. 1990. L’Cvolution des mtthodes et des langages de simulation. Page 119 in ModClisation Sysdmique et Systtme Agraire. Mcision et Organisation. J. Brossier, B. Vissac, and J. L. Le Moigne, ed. Inst. Natl. Rech. Agron., Versailles, France. 3 Chen, P. P. 1976. The entity-relationship model. Toward a unified view of data. ACM T. (Assoc. Comput. Machinery Trans.) Database Syst. 1:9. 4Codd. E. F. 1972. Further normalization of the database relational model. Page 33 in Data Base Systems. R. Rustin, ed. Prentice-Hall, Englewood Cliffs, NJ. 5 Codd, E. F. 1974. Recent investigations in relational data base systems. Page 1017 in Information Processing 74. Proc. Int. Fed. Infomation Processing Congr. 74. J. L. Rosenfeld. ed. North Holland, Amsterdam, Neth. 6 Esslemont, R. J., A. J. Stephens, and D. R. Ellis. 1981. Dairy herd management. Occas. Publ. Br. SOC.Anim Prod. 5:21. 7 Faye, B., J. Bamouin, and F. Lescourret. 1989. Objectifs principaux et strattgie de I’enquete tcopathologique Bretagne sur la vache laititre. Epid6miol. SantC Anim. 1523. 8 Gauthier, L., and R. Kok. 1988. A microcomputerbased farm managemenuoperating system. Can. Agric. Eng. 30:69.

1061

9 Hainaut. J. L., and B. Lecharlier. 1974. An extensible semantic model of data base and its data language. Page 1026 in Information Processing 74. Proc. Int. Fed. Information Processing Congr. 74. J. L. Rosenfeld. ed. North Holland, Amsterdam. Neth. IOLescourret, F., L. Ptrochon, J. B. Coulon, B. Faye, and E. Landais. 1992. Modelling and information system using the MERISE method for agricultural research: the example of a database for a study on performances in dairy cows. Agric. Syst. 38:149. 11 Martin, B., D. D. Mainland, and M. A. Green. 1982. VIRUS: a computer program for herd health and productivity. Vet. Rec. 110:446. 12McIlroy, S. G.. E. A. Goodall. J. Rainey, and C. H. McMurray. 1988. A computerized management and disease information retrieval system for profitable broiler production. Agric. Syst. 27:ll. 13 Moulin, P., J. Randon, M. Teboul, S. Savoysky, S. Spaccapietra, and H. Tardieu. 1976. Conceptual model as data base design tool. Page 221 in Modelling in Data Base Management Systems. Proc. Int. Fed. Information Processing Working Conf. Modelling Data Base Manage. Syst. G . M. Nijssen, ed. North Holland. Amsterdam, Neth. 14Noordhuizen, J.P.T.M., and J. Buurman, 1984. VAMPP: a veterinary automated management and production controle programme for dairy farms (the application of MUMPS for data processing). Vet. Q. 6:67. 15 Rolland, C. 1986. Introduction B la conception de systtmes d’information et panorama des mtthodes disponibles. Genie Logiciel 4:6. 16RowIands, G. J. 1983. Data standards for computer systems in livestock recording for dairy herd management. Livest. Prod. Sci. 10:419. 17Russel. A. M., and G . J. Rowlands. 1983. COSREEEL: Computerised recording system for herd health information management. Vet. Rec.112:189. 18Stone. D.J.W., and M. V. Thrusfietd. 1989. A small animal clinical and epidemiological relational database. Rev. Vet. Med. 7:289. 19 Tardieu, H., A. Rochfeld, and R. Coletti. 1983. La m6thode MERISE. Tome I. Principes et Outils. Les Editions d’Organisation, Paris, France. 20 Thrustield, M. 1986. Veterinary disease information systems. Page 89 in Proc. 4th Int. Symp. Vet. Epidemiol. Econ. Singapore Vet. Assoc. Singapore, Singapore. 21 Udomprasert, P., and N. B. Williamson. 1990. The Dairychamp program: a computerised recording system for dairy herds. Vet. Rec. 127:256.

Journal of Dairy Science Vol. 76, No. 4, 1993

1062

LESCOURRET ET AL. APPENDIX

Examples of Retrievals from the Relational Database Tables

The following queries use SQL*Plus, the query language of the relational database management system Oracle (Oracle Corporation, Belmont, CA). 1. select count(cow number), breed, farm code from “cow” group by breed, farm code; 2. select “lactation” .cow number, “lactation” .lactation number from “lactation”,“cow disease” where “lactation”.starting date between ’1-JAN-87’ and ‘31-DEC-87’ and “lactation”.cow number = “cow disease”.cow number and “lactation”.lactation number = “COW disease”.lactation number and disease code like ‘M%’; where M% is understood by SQL*Plus as corresponding to any of the codes beginning by M (= any type of clinical mastitis). Any column is identified in the query by table name.column name. 3. select cow number, 1, “yearly practice” .PI, . . . , “yearly practice”.pi from “cow disease”, “cow”, “yearly practice” where “COW disease”.cow number = “cow”.cow number and “cow” .farm code = “yearly practice”.farm code and “yearly practice”.year = 87 and disease date between ‘1-JAN-87’ and ‘31- DEC-87’ union select cow number, 0, “yearly practice” .pl, . . . , “yearly practice” .pi from “cow”, “yearly practice” and “cow”.farm code = “yearly practice”.farm code and “yearly practice”.year = 87 and exit date >=‘2-JAN-87’ and not exists (select cow number from “cow disease” where cow number = “cow”.cow number and disease date between ‘1-JAN-87’ and ‘31-DEC-87’);

Note that “union” is a set operation. Cows having suffered at least from one disease during the year 1987, recorded in “cow disease” with restriction on the date, are first selected (above “union”). Cows both present in the survey during at least 1 d in 1987 and healthy during this period (absent from “cow disease” restricted to the relevant dates) are then selected (below “union”).

Journal of Dairy Science Vol. 76, No. 4, 1993