Манипулирование данными

После ввода данных в реляционной базе данных, пользователи могут делать запросы и анализировать данные. Основные манипуляции данных входить выбор, проектирование и объединение. Выбор предусматривает исключение строк в соответствии с определенными критериями. Предположим, таблица проект содержит ряд проектов, описание и номер отдела для всех проектов компания выполняет. Президент компании, возможно, захотите, чтобы найти номер отдела для проекта 226, проект ручного продаж. Использование выбор, президент может устранить все строки, но тот, для реализации проекта 226 и увидеть, что номер отдела в департаменте завершения проекта руководство продаж 598.

Проектирование предусматривает исключение столбцов в таблице. Например, таблица отделов может содержать номер отдела, название отдела, и номер социального страхования (SSN) менеджера, ответственного за проект. Менеджер по продажам может потребоваться создать новую таблицу только номер отдела и номер социального страхования менеджера, ответственного за проект ручного продаж. Менеджер по продажам может использовать проекцию, чтобы исключить столбец название отдела и создать новую таблицу, содержащую только номер отдела и номер социального страхования.

Присоединение предполагает объединение двух или более таблиц. Например, вы можете объединить Таблица проекта и таблица отделов, чтобы создать новую таблицу с указанием числа проектов, описание проекта, номер отдела, название отдела, и номер социального страхования для менеджера, ответственного за проект.

Пока таблицы разделить по меньшей мере, один атрибут общих данных в таблицах реляционной базы данных могут быть связаны, чтобы обеспечить полезную информацию и отчеты. Будучи в состоянии связать таблицы друг с другом через общих атрибутов данных является одним из ключей к гибкости и мощности реляционных баз данных. Предположим, президент компании хочет узнать имя менеджера проекта ручной продажи и продолжительность времени, менеджер был с компанией. Предположим, что компания имеет менеджер, Отдел и таблицы Проект, показанный на рисунке 5.5. Упрощенная ER-схема, показывающая взаимосвязь между этими таблицами показано на рисунке 5.6. Обратите внимание на crow's ногой на столе проекта. Это означает, что отдел может иметь много проектов. Президент сделает запрос к базе данных, возможно, с помощью персонального компьютера. СУБД хотел бы начать с описания проекта и искать в таблице проекта, чтобы узнать номер отдела проекта. Было бы затем использовать номер отдела искать таблицу отделов для номера социального страхования менеджера. Отдел номер также в таблице отделов и общий элемент, который связывает таблицу проекта к столу отдела СУБД использует номер социального страхования менеджера для поиска Управляющая таблица на дату нанять менеджера. Номер социального страхования менеджера является общим элементом между столом отдела и стол менеджера. Конечный результат в том, что имя менеджера и дата нанять представлены президенту в ответ на запрос (рис 5.7).

Одним из основных преимуществ реляционной базы данных является то, что она позволяет таблицы должны быть связаны, как показано на рисунке 5.7. Эта связь особенно полезно, когда информация нужна из нескольких таблиц. Например, номер социального страхования менеджера поддерживается в таблице менеджера. Если номер социального страхования необходимо, оно может быть получено путем ссылки к таблице менеджера.

Реляционная модель базы данных на сегодняшний день является наиболее широко используется. Это легче контролировать, более гибкими и более интуитивно, чем другие подходы, потому что она организует данные в таблицах. Как показано на рисунке 5.8, в системе управления реляционными базами данных, таких как Access, дает советы и инструменты для построения и использования таблиц базы данных. На этой фигуре, в базе данных отображается информация о типах данных и указывает, что дополнительная помощь доступна. Способность связывать реляционных таблиц также позволяет пользователям связать данные по-новому, не имея пересмотреть сложные отношения. Из-за преимуществ реляционной модели, многие компании используют его для крупных корпоративных баз данных, таких как те, для маркетинга и бухгалтерского учета. Реляционная модель также может быть использован с персональными компьютерами и мэйнфреймы. Бронирование туристическая компания, например, может разработать систему тариф ценообразования с использованием технологии реляционных баз данных который может обрабатывать миллионы ежедневных запросов из Интернета туристических компаний, таких как Expedia, Travelocity, и Orbitz.

Data Cleanup

As discussed in Chapter 1, valuable data is accurate, complete, economical, flexible, reliable, relevant, simple, timely, verifiable, accessible, and secure. The database must also be properly designed. The purpose of data cleanup is to develop data with these characteristics. Considera database for a fitness center designed to track member dues. The table contains the attribute name, phone number, gender, dues paid, and date paid (see Table 5.3). As the records in Table 5.3 show, Anita Brown and Sim Thomas have paid their dues in September. Sim has paid his dues in two installments. Note that no primary key uniquely identifies each record. As you will see next, this problem must be corrected.

Because Sim Thomas has paid dues twice in September, the data in the database is now redundant. The name, phone number, and gender for Thomas are repeated in two records. Notice that the data in the database is also inconsistent: Thomas has changed his phone number, but only one of the records reflects this change. Further reducing this database’s reliability is the lack of a primary key to uniquely identify Sim Thomas’s record. The first Thomas could be Sim Thomas, but the second might be Steve Thomas. These problems and irregularities in data are called anomalies. Data anomalies often result in incorrect information, causing database users to be misinformed about actual conditions. Anomalies must be corrected.

To solve these problems in the fitness center’s database, we can add a primary key, such as member number, and put the data into two tables: a Fitness Center Members table with gender, phone number, and related information, and a Dues Paid table with dues paid and date paid (see Tables 5.4 and 5.5). Both tables include the member number attribute so that they can be linked.

The relations in Table 5.4 and Table 5.5 reduce the redundancy and eliminate the potential problem of having two different phone numbers for the same member. Also note that the member number gives each record in the Fitness Center Members table a primary key. Because the Dues Paid table lists two payment entries ($15 each) with the same member number (SN656), one person clearly made the payments, not two different people. Formalized approaches, such as database normalization, are often used to clean up problems with data.