IDMS: История и Развитие Системы Управления Базами Данных

Введение

Изотопная разбавленная масс-спектрометрия

Интегрированная система управления базами данных (IDMS) — это система управления базами данных сетевой модели (CODASYL) для мэйнфреймов. Она была впервые разработана в компании B. F. Goodrich, а затем продана компании Cullinane Database Systems (переименованной в Cullinet в 1983 году). С 1989 года продукт принадлежит компании Computer Associates (ныне CA Technologies), которая переименовала его в Advantage CA IDMS, а затем просто в CA IDMS. В 2018 году компания Broadcom приобрела CA Technologies, вернув ей название IDMS.

История

Корни IDMS уходят в пионерскую систему управления базами данных под названием Integrated Data Store (IDS), разработанную в General Electric командой во главе с Чарльзом Бахманом и впервые выпущенную в 1964 году. В начале 1960-х годов IDS была взята из ее первоначальной формы компьютерной группой химического отдела B. F. Goodrich и переписана на языке, называемом Intermediate System Language (ISL). ISL был разработан как портативный язык системного программирования, способный создавать код для различных целевых машин. Поскольку ISL был на самом деле написан на ISL, его можно было относительно легко перенести на другие машинные архитектуры, а затем создать код для выполнения на них. Компьютерная группа химического подразделения рассматривала возможность продажи копий IDMS другим компаниям, но руководство сообщило, что они не занимаются производством программного обеспечения. В конечном итоге было заключено соглашение с Джоном Куллианом о покупке прав и маркетинге продукта. Поскольку Куллиан должен был выплачивать B. F. Goodrich роялти, все дополнительные продукты были перечислены и выставлялись как отдельные продукты – даже если они были обязательны для работы основного продукта IDMS. Это иногда вводило клиентов в заблуждение. Первоначальными платформами были компьютер GE 235 и компьютер с коммутацией сообщений GE DATANET 30: позже продукт был портирован на мэйнфреймы IBM и на аппаратное обеспечение DEC и ICL. Портированная версия IBM работает на мэйнфреймовых системах IBM (System/360, System/370, System/390, zSeries, System z9). В середине 1980-х годов утверждалось, что было продано около 2500 лицензий IDMS. Среди пользователей были Strategic Air Command, Ford of Canada, Ford of Europe, Jaguar Cars, Clarks Shoes UK, AXA/PPP, MAPFRE, Royal Insurance, Tesco, Manulife, Hudson's Bay Company, Cleveland Clinic, Bank of Canada, General Electric, Aetna и BT в Великобритании. Версия для использования на компьютерах серии PDP 11 Digital Equipment Corporation была продана DEC и продавалась как DBMS 11. В 1976 году исходный код был лицензирован ICL, которая портировала программное обеспечение для работы на своих мэйнфреймах серии 2900, а затем и на более старые модели 1900. ICL продолжала разработку программного обеспечения независимо от Cullinane, продавая оригинальный портированный продукт под названием ICL 2900 IDMS, а улучшенную версию – как IDMSX. В этой форме она использовалась многими крупными пользователями Великобритании, например, системой уплаты подоходного налога Inland Revenue. Многие из этих систем IDMSX для правительства Великобритании все еще работали в 2013 году. В начале – середине 1980-х годов системы управления реляционными базами данных стали набирать популярность, чему способствовало увеличение вычислительной мощности оборудования и переход к миникомпьютерам и клиент-серверной архитектуре. Реляционные базы данных предлагали повышенную производительность разработки по сравнению с системами CODASYL, а традиционные возражения, основанные на низкой производительности, постепенно отпадали. Cullinet попыталась конкурировать с IBM DB2 и другими реляционными базами данных, разработав реляционный интерфейс и ряд инструментов повышения производительности. Среди них был Automatic System Facility (ASF), который использовал существующую функцию IDMS под названием LRF (Logical Record Facility). ASF был генератором баз данных, работающим по принципу заполнения пропусков, который также разрабатывал мини-приложение для обслуживания таблиц. Трудно судить, были ли эти функции успешными в продлении срока службы продукта, но в долгосрочной перспективе они оказали незначительное влияние. Пользователи, оставшиеся с IDMS, были в первую очередь заинтересованы в его высокой производительности, а не в реляционных возможностях. Широко признавалось (благодаря масштабной кампании Э. Ф. Кодда, отца реляционной модели), что существует значительная разница между реляционной базой данных и сетевой базой данных с реляционным интерфейсом. В 1989 году Computer Associates, после приобретения Cullinet, продолжила разработку и выпустила Release 12.0 с полной поддержкой SQL в 1992–93 годах. CA Technologies продолжала продавать и поддерживать CA IDMS и расширенные версии IDMS в последующих релизах, добавив поддержку TCP/IP, поддержку двухфазных коммитов, публикацию XML, поддержку специализированных процессоров zIIP, веб-доступ в сочетании с CA IDMS Server, SQL Option и администрирование баз данных с графическим интерфейсом через инструмент CA IDMS Visual DBA. Системы CA IDMS до сих пор используются в бизнесе по всему миру. Многие клиенты выбрали возможность веб-интеграции своих приложений через CA IDMS SQL Option, который является частью стратегии Dual Database Strategy компании CA Technologies.

The roots of IDMS go back to the pioneering database management system called Integrated Data Store (IDS), developed at General Electric by a team led by Charles Bachman and first released in 1964. In the early 1960s IDS was taken from its original form, by the computer group of the B. F. Goodrich Chemical Division, and re written in a language called Intermediate System Language (ISL). ISL was designed as a portable system programming language able to produce code for a variety of target machines. Since ISL was actually written in ISL, it was able to be ported to other machine architectures with relative ease, and then to produce code that would execute on them. The Chemical Division computer group had given some thought to selling copies of IDMS to other companies, but was told by management that they were not in the software products business. Eventually, a deal was struck with John Cullinane to buy the rights and market the product. Because Cullinane was required to remit royalties back to B. F. Goodrich, all add on products were listed and billed as separate products – even if they were mandatory for the core IDMS product to work. This sometimes confused customers. The original platforms were the GE 235 computer and GE DATANET 30 message switching computer: later the product was ported to IBM mainframes and to DEC and ICL hardware. The IBM ported version runs on IBM mainframe systems (System/360, System/370, System/390, zSeries, System z9). In the mid 1980s, it was claimed that some 2,500 IDMS licenses had been sold. Users included the Strategic Air Command, Ford of Canada, Ford of Europe, Jaguar Cars, Clarks Shoes UK, AXA/PPP, MAPFRE, Royal Insurance, Tesco, Manulife, Hudson's Bay Company, Cleveland Clinic, Bank of Canada, General Electric, Aetna and BT in the UK. A version for use on the Digital Equipment Corporation PDP 11 series of computers was sold to DEC and was marketed as DBMS 11. In 1976 the source code was licensed to ICL, who ported the software to run on their 2900 series mainframes, and subsequently also on the older 1900 range. ICL continued development of the software independently of Cullinane, selling the original ported product under the name ICL 2900 IDMS and an enhanced version as IDMSX. In this form it was used by many large UK users, an example being the Pay As You Earn system operated by Inland Revenue. Many of these IDMSX systems for UK Government were still running in 2013. In the early to mid 1980s, relational database management systems started to become more popular, encouraged by increasing hardware power and the move to minicomputers and client–server architecture. Relational databases offered improved development productivity over CODASYL systems, and the traditional objections based on poor performance were slowly diminishing. Cullinet attempted to continue competing against IBM's DB2 and other relational databases by developing a relational front end and a range of productivity tools. These included Automatic System Facility (ASF), which made use of a pre existing IDMS feature called LRF (Logical Record Facility). ASF was a fill in the blanks database generator that would also develop a mini application to maintain the tables. It is difficult to judge whether such features may have been successful in extending the selling life of the product, but they made little impact in the long term. Those users who stayed with IDMS were primarily interested in its high performance, not in its relational capabilities. It was widely recognized (helped by a high profile campaign by E. F. Codd, the father of the relational model) that there was a significant difference between a relational database and a network database with a relational veneer. In 1989 Computer Associates continued after Cullinet acquisition with the development and released Release 12.0 with full SQL in 1992–93. CA Technologies continued to market and support the CA IDMS and enhanced IDMS in subsequent releases by TCP/IP support, two phase commit support, XML publishing, zIIP specialty processor support, Web enabled access in combination with CA IDMS Server, SQL Option and GUI database administration via CA IDMS Visual DBA tool. CA IDMS systems are today still running businesses worldwide. Many customers have opted to web enable their applications via the CA IDMS SQL Option which is part of CA Technologies' Dual Database Strategy.

Интегрированный словарь данных

Одной из передовых возможностей IDMS был встроенный интегрированный словарь данных (IDD). IDD был разработан главным образом для ведения определений баз данных. Сам по себе он являлся базой данных IDMS. Администраторы баз данных (DBA) и другие пользователи взаимодействовали с IDD, используя язык определения словаря данных (DDDL). IDD также использовался для хранения определений и кода для других продуктов семейства IDMS, таких как ADS/Online и IDMS DC. Главным преимуществом IDD была его расширяемость, позволявшая создавать определения практически для любых объектов. Некоторые компании использовали его для разработки внутренней документации.

Логическая модель данных

Модель данных, предлагаемая пользователям, – это сетевая модель CODASYL. Основными структурами в этой модели являются записи и наборы. Записи по существу следуют структуре COBOL, состоящей из полей различных типов: это позволяет создавать сложную внутреннюю структуру, такую как повторяющиеся элементы и группы. Наиболее характерной концепцией структурирования в модели Codasyl является набор. Не следует путать с математическим множеством, набор Codasyl представляет собой связь «один ко многим» между записями: один владелец, много членов. Тот факт, что запись может быть членом многих различных наборов, является ключевым фактором, отличающим сетевую модель от более ранней иерархической модели. Как и в случае с записями, каждый набор принадлежит к именованному типу наборов (разные типы наборов моделируют различные логические отношения). Наборы, по сути, упорядочены, и последовательность записей в наборе может использоваться для передачи информации. Запись может участвовать как владелец и член любого количества наборов. Записи имеют идентификатор, который представлен значением, известным как ключ базы данных. В IDMS, как и в большинстве других реализаций Codasyl, ключ базы данных напрямую связан с физическим адресом записи на диске. Ключи базы данных также используются в качестве указателей для реализации наборов в виде связных списков и деревьев. Это тесное соответствие между логической моделью и физической реализацией (которое не является строго необходимой частью модели Codasyl, но было характерно для всех успешных реализаций) обеспечивает эффективность поиска в базе данных, но также делает операции, такие как загрузка базы данных и реструктуризация, достаточно затратными. Доступ к записям может осуществляться непосредственно по ключу базы данных, путем следования по связям наборов или путем прямого доступа с использованием ключевых значений. Первоначально единственный прямой доступ был реализован через хеширование, механизм, известный в модели Codasyl как CALC-доступ. В IDMS CALC-доступ реализуется через внутренний набор, связывающий все записи, имеющие одинаковое хеш-значение, с владельческой записью, которая занимает первые несколько байтов каждой страницы диска. В последующие годы некоторые версии IDMS добавили возможность доступа к записям с использованием индексов, подобных B-деревьям.

The data model offered to users is the CODASYL network model. The main structuring concepts in this model are records and sets. Records essentially follow the COBOL pattern, consisting of fields of different types: this allows complex internal structure such as repeating items and repeating groups. The most distinctive structuring concept in the Codasyl model is the set. Not to be confused with a mathematical set, a Codasyl set represents a one to many relationship between records: one owner, many members. The fact that a record can be a member in many different sets is the key factor that distinguishes the network model from the earlier hierarchical model. As with records, each set belongs to a named set type (different set types model different logical relationships). Sets are in fact ordered, and the sequence of records in a set can be used to convey information. A record can participate as an owner and member of any number of sets. Records have identity, the identity being represented by a value known as a database key. In IDMS, as in most other Codasyl implementations, the database key is directly related to the physical address of the record on disk. Database keys are also used as pointers to implement sets in the form of linked lists and trees. This close correspondence between the logical model and the physical implementation (which is not a strictly necessary part of the Codasyl model, but was a characteristic of all successful implementations) is responsible for the efficiency of database retrieval, but also makes operations such as database loading and restructuring rather expensive. Records can be accessed directly by database key, by following set relationships, or by direct access using key values. Initially the only direct access was through hashing, a mechanism known in the Codasyl model as CALC access. In IDMS, CALC access is implemented through an internal set, linking all records that share the same hash value to an owner record that occupies the first few bytes of every disk page. In subsequent years, some versions of IDMS added the ability to access records using BTree like indexes.

Хранение

IDMS организует свои базы данных в виде ряда файлов. Эти файлы отображаются и предварительно форматируются в так называемые области. Области подразделяются на страницы, которые соответствуют физическим блокам на диске. Записи базы данных хранятся в этих блоках. DBA выделяет фиксированное количество страниц в файле для каждой области. Затем DBA определяет, какие записи должны храниться в каждой области, и детали того, как они должны быть сохранены. IDMS распределяет специальные страницы выделения пространства по всей базе данных. Эти страницы используются для отслеживания свободного пространства, доступного на каждой странице в базе данных. Для снижения требований к вводу-выводу свободное пространство отслеживается только для всех страниц, когда свободное пространство для области опускается ниже 30%. Для хранения записей в базе данных IDMS доступны четыре метода: Прямой, Последовательный, CALC и VIA. Версия Fujitsu/ICL IDMSX расширяет этот список еще двумя методами: Page Direct и Random. В прямом режиме пользователь указывает целевой ключ базы данных, и запись хранится как можно ближе к этому ключу, при этом фактический ключ базы данных, на котором хранится запись, возвращается в прикладную программу. Последовательное размещение (не следует путать с индексированным последовательным) просто помещает каждую новую запись в конец области. Этот вариант используется редко. CALC использует алгоритм хеширования для определения места размещения записи; затем хеш-ключ обеспечивает эффективное извлечение записи. Вся область CALC предварительно форматируется, каждая из них содержит заголовок, состоящий из специальной записи "владелец" CALC. Алгоритм хеширования определяет номер страницы (на основе которого можно определить физический адрес диска), и запись затем сохраняется на этой странице или как можно ближе к ней, и связывается с записью заголовка на этой странице с использованием набора CALC. Записи CALC связаны с записью владельца CALC страницы с помощью односвязного списка (указателей). Владелец CALC, расположенный в заголовке страницы, таким образом, владеет набором всех записей, ориентированных на его конкретную страницу (независимо от того, хранятся ли записи на этой странице или, в случае переполнения, на другой странице). CALC обеспечивает чрезвычайно эффективное хранение и извлечение: IDMS может извлечь запись CALC примерно за 1.1 операций ввода-вывода. Однако метод плохо справляется с изменениями значения первичного ключа, и требуется дорогостоящая реорганизация, если необходимо увеличить количество страниц. В качестве обходного пути можно расширить область, а затем запустить прикладную программу, которая последовательно сканирует область для каждой записи CALC и использует оператор MODIFY для обновления каждой записи. Это приводит к тому, что каждая запись CALC связывается с набором CALC для правильной целевой страницы, рассчитанной для нового диапазона страниц области. Недостатком этого метода является то, что очень мало записей CALC окажется на своих целевых страницах, и навигация по набору CALC каждой страницы, вероятно, потребует большого количества операций ввода-вывода. В результате этого рекомендуется использовать этот обходной путь только в крайних случаях, так как производительность снизится. Размещение VIA пытается хранить запись рядом с ее владельцем в определенном наборе. Обычно записи кластеризуются на той же физической странице, что и владелец. Это обеспечивает эффективную навигацию при доступе к записи по этой установленной связи. (VIA позволяет хранить записи в другой области IDMS, чтобы они могли храниться отдельно от владельца, но оставаться сгруппированными для повышения эффективности. В IDMSX они также могут быть смещены от владельца на определенное количество страниц). Page Direct (только IDMSX) аналогичен режиму Direct, однако указывается номер целевой страницы базы данных, и запись связывается с цепочкой CALC для этой страницы. Random (только IDMSX) выделяет номер целевой страницы записи при ее хранении с использованием алгоритма CALC (это может использовать ключ внутри записи или, в случае неключевого случайного доступа, использовать дату и время хранения в качестве начального значения для алгоритма CALC). Наборы данных обычно поддерживаются в виде односвязных списков, используя ключ базы данных в качестве указателя. Каждая запись включает прямую ссылку на следующую запись; разработчик базы данных может выбрать, включать ли указатели владельца и указатели на предыдущую запись (если они не указаны, навигация в этих направлениях будет медленнее). В некоторых версиях IDMS впоследствии была добавлена возможность определения индексов: индексы записей, позволяющие находить записи по значению вторичного ключа, или индексы наборов, позволяющие извлекать элементы набора по значению ключа. Записи размещения IDMSX Page Direct и Random обычно используются в сочетании с индексами записей, как описано выше. Сами индексы подчиняются правилам размещения, либо Direct (что фактически означает "CALC с использованием ID индекса в качестве ключа"), либо CALC.

IDMS organizes its databases as a series of files. These files are mapped and pre formatted into so called areas. The areas are subdivided into pages which correspond to physical blocks on the disk. The database records are stored within these blocks. The DBA allocates a fixed number of pages in a file for each area. The DBA then defines which records are to be stored in each area, and details of how they are to be stored. IDMS intersperses special space allocation pages throughout the database. These pages are used to keep track of the free space available in each page in the database. To reduce I/O requirements, the free space is only tracked for all pages when the free space for the area falls below 30%. Four methods are available for storing records in an IDMS database: Direct, Sequential, CALC, and VIA. The Fujitsu/ICL IDMSX version extends this with two more methods, Page Direct, and Random. In direct mode the target database key is specified by the user and is stored as close as possible to that DB key, with the actual DB key on which the record is stored being returned to the application program. Sequential placement (not to be confused with indexed sequential), simply places each new record at the end of the area. This option is rarely used. CALC uses a hashing algorithm to decide where to place the record; the hash key then provides efficient retrieval of the record. The entire CALC area is preformatted each with a header consisting of a special CALC "owner" record. The hashing algorithm determines a page number (from which the physical disk address can be determined), and the record is then stored on this page, or as near as possible to it, and is linked to the header record on that page using the CALC set. The CALC records are linked to the page's CALC Owner record using a single link list (pointers). The CALC Owner located in the page header thus owns the set of all records which target to its particular page (whether the records are stored on that page or, in the case of an overflow, on another page ). CALC provides extremely efficient storage and retrieval: IDMS can retrieve a CALC record in 1.1 I/O operations. However, the method does not cope well with changes to the value of the primary key, and expensive reorganization is needed if the number of pages needs to be expanded. A work around is to expand the area, and then run an application program which scans the area sequentially for each CALC record, and then uses the MODIFY verb to update each record. This results in each CALC record being connected to the CALC Set for the correct target page as calculated for the Area's new page range. The downside to this method is that vanishingly few CALC records will now be on their target pages, and navigating each page's CALC set is likely to involve many IO operations. As a result, it is recommended only to use this work around in extreme circumstances as performance will suffer. VIA placement attempts to store a record near its owner in a particular set. Usually the records are clustered on the same physical page as the owner. This leads to efficient navigation when the record is accessed by following that set relationship. (VIA allows records to be stored in a different IDMS area so that they can be stored separately from the owner, yet remain clustered together for efficiency. Within IDMSX they may also be offset from the owner by a set number of pages). Page Direct (IDMSX only) is similar to Direct mode, however a target Database page number is specified and the record is connected to the CALC chain for that page. Random (IDMSX only) allocates a target page number to the record occurrence when it is stored using the CALC algorithm (this either uses a Key within the record or in the case of un keyed random, uses the date & time of storage as a seed for the CALC algorithm). Sets are generally maintained as linked lists, using the database key as a pointer. Every record includes a forward link to the next record; the database designer can choose whether to include owner pointers and prior pointers (if not provided, navigation in those directions will be slower). Some versions of IDMS subsequently included the ability to define indexes: either record indexes, allowing records to be located from knowledge of a secondary key, or set indexes, allowing the members of a set to be retrieved by key value. The IDMSX Page Direct and Random placement records are typically used in conjunction with Record Indexes as described above. The Indexes themselves are subject to placement rules, either Direct (which really means "CALC using the Index ID as the key") or CALC.