Классикалық Mac OS: Деректерге қолжеткізу менеджері (DAM) API

Кіріспе

Classic Mac OS API
Деректерге қол жеткізу менеджері (DAM) – 1991 жылы System 7 кеңейтуі ретінде ұсынылған, классикалық Mac OS жүйесі үшін деректер қорына қол жеткізу API. ODBC-ге ұқсас DAM аз қолданылды және 1990 жылдардың соңында тоқтатылды. Оны тек бірнеше өнім қолданған, бірақ 1990 жылдардың басында ол өте әсерлі демонстрациялық бағдарламалар жасау үшін пайдаланылды. Классикалық Mac OS және macOS-тің жаңа нұсқалары осы мақсатта ODBC-ді пайдаланады.

Тұжырымдамалар

DAM және ODBC көптеген жағынан ұқсас. Екі жүйенің де негізгі мақсаты – деректерді жеткізушіге «сұрау жолдары» жіберу, ол (мүмкін) деректердің қатарларынан тұратын «нәтижелер жиынтығымен» жауап береді. Екі жүйе де деректерді жүйелердің тиісті пішімдеріне, мысалы, бүтін сандар мен жолдарға аударуды күтеді. Сонымен қатар, екеуі де клиенттер мен серверлер арасындағы сұрауларды және деректерді жіберудің егжей-тегжейін жасыратын байланыс жүйесін ұсынды. Apple бағдарламалық жасақтамаларының көпшілігі сияқты, DAM пайдаланушылар үшін сұрау процесін мүмкіндігінше қарапайым етуге тырысты, бұл қолданбаларды пайдаланушылар мен осы қолданбаларды жазатын бағдарламалаушылар үшін де осылай болды. Бір ерекше ерекшелігі – «сұрау құжаттары» тұжырымы. Сұрау құжаттарында серверге жіберілгенге дейін оларды өзгерту үшін қосымша кодпен бірге алдын ала анықталған сұраулардың (немесе басқа серверлік командалардың) кез келген саны болуы мүмкін. Мысалы, әдеттегі сұрау құжатында деректер базасы серверіне кіруге арналған сұрау жолы болуы мүмкін, және егер ол сәтті аяқталса, Mac OS шақыруын пайдаланып жергілікті клиенттік машинадан ағымдағы күнді анықтап, содан кейін сол күнді берілген күндік қоймадағы тауар тізімін қайтаратын сұрау үшін пайдалануға болады. Сұрау құжаттарына осы процесті қолдау үшін қажетті компьютерлік код пен ресурстар, мысалы, пайдаланушы атын және құпия сөзді сұрайтын әңгіме терезесі де кіруі мүмкін. Қолданбалар сұраудың ішкі құрылымын білмей-ақ сұрау құжаттарын пайдалана алады. Олар тек ресурстардан тұратын құжатты ашып, әр сұрау ресурсын кезекпен орындайды. DAM құжаттағы қажетті кодтың қолданбаның білмеуінен орындалуын қамтамасыз етеді, содан кейін нәтижелер қолданбаға көрсету үшін қайтарылады. Бүкіл операция жасырын болды, бұл қолданбаларға DAM қолдауын оңай қосуға мүмкіндік берді. DAM сонымен қатар екі тікелей API-ді де қамтыды: жоғары деңгейлі интерфейс және төменгі деңгейлі интерфейс. Жоғары деңгейлі интерфейс сұрау құжаттарын пайдалануға өте ұқсас, бірақ қолданба сұрауларды ресурстардың орнына кодта құрастырады деп күтілді. Жоғары деңгейлі интерфейс негізінен ODBC-нің ашық интерфейсіне ұқсас. Төменгі деңгейлі интерфейс бағдарламалаушыға сұрау процесінің кез келген нүктесінде араласуға мүмкіндік береді, мысалы, деректерді жол бойынша жолмен алуға болады. DAM мен ODBC арасындағы бір маңызды айырмашылық көбінесе кездейсоқ жағдайда туындады. DAM-ді әзірлеуге дейін Apple деректер базасының орталық бағдарламалық жасақтамасын сатып алып, оны Data Access Language (DAL) деп сатты. DAL негізінен серверлік жағында жұмыс істейтін әртүрлі деректер базаларына арналған аудармашылары бар стандартталған SQL болды. SQL стандарттары сол кезде өте қарапайым болды және жеткілікті қолдау көрсетілмеді, DAL бұл мәселені бір тілді пайдаланып және басқа жүйелерге және олардан аударту арқылы шешті. Клиенттік бағдарламалық қамтамасыз ету, соның ішінде DAM, DAL стандартты тілінде сұрауларды жібере алады, олар кейін аудармаға алынып, артқы деректер базасына қарамастан орындалады. Керісінше, ODBC бастапқыда X/Open (қазір Open Group құрамында) стандартталған Call Level Interface негізінде SQL негізделген жүйе ретінде әзірленді. ODBC бойынша әрбір дерек көзі SQL сервері сияқты көрінеді. Серверсіз дерек көздері үшін, мысалы, мәтіндік файлдар үшін, жергілікті SQL талдаушысы командаларды түсіндіріп, файлды оқиды. ODBC аясында барлық дерек көзі драйверлері SQL-ді түсінуі және қажет болған жағдайда оны жергілікті диалектке аударуы, сондай-ақ деректерді стандартты форматқа қайтаруы керек. Бұл айырмашылық DAM-ді практикада ODBC-ге қарағанда әлдеқайда аз пайдалы етті. DAL сұрауларды стандарттауды қамтамасыз етеді деп күтілгендіктен, DAM-де ODBC-ге ұқсас әртүрлі диалекттерді аудару үшін қабат болған жоқ. DAM-нің шынымен пайдалы болуы үшін пайдаланушы өзінің жеке деректер базасы үшін DAL серверін сатып алып, орнатуы керек еді. DAL жалпы алғанда баяу және қымбат екендігі белгілі болды, бұл DAM-нің жалпы құнын төмендетті. Сонымен қатар, DAM SQL емес дерек көздеріне қол жеткізу үшін тілді стандарттаған жоқ; мәтіндік файлға арналған адаптер SQL емес тілді немесе толық функцияны шақыру жүйесіне негізделген жүйені пайдалануы мүмкін. Сондай-ақ, DAM-нің негізгі орнатуларына мәтіндік файлдар немесе ұқсас дерек көздері үшін қарапайым интерфейстер енгізілген жоқ.

DAM and ODBC are similar in many ways. The primary purpose of both systems was to send "query strings" to a data provider, who would respond (potentially) with a "result set" consisting of rows of data. Both systems were expected to convert data to and from the system's respective formats, integers and strings for instance. Additionally, both provided a communications subsystem that hid the details of sending queries and data between the client and server. Like most Apple software, DAM attempted to make the query process as simple as possible for the users, both application users and programmers writing those applications. One particularly notable feature was the concept of "query documents". Query documents contained any number of pre defined queries (or other server commands), along with optional code to modify them before being sent to the server. For instance, a typical query document might contain a query string that would log into the database server, and if that was successful, look up the current date from the local client machine using a Mac OS call, and then use that date in a query that returns inventory in a warehouse for a given date. Query documents could also include computer code and resources needed to support this process, for instance, a dialog box asking for the username and password. Applications could use query documents without having any idea of the internals of the query. They simply opened the document, which consisted of a series of resources, and ran each query resource inside in turn. The DAM would ensure that any needed code in the document would be run without the application even being aware of it, and eventually, results would be passed back to the application for display. The entire operation was opaque, allowing applications to add DAM support with ease. DAM also included two more direct API's, the High Level interface, and the Low Level interface. High Level was fairly similar to using query documents, although it was expected that the application would construct the queries in code rather than resources. The High Level interface is broadly similar to ODBC's public interface. Low Level allowed the programmer to intercede at any point in the query process, retrieving data line by line for instance. One major difference between DAM and ODBC came about largely by accident. Prior to the development of DAM, Apple had purchased a database middleware product they sold as the Data Access Language, or DAL. DAL was essentially a standardized SQL with translators for various databases that ran on the server side. Standards for SQL were extremely basic at the time, and relatively poorly supported, DAL addressed this by having a single language and converting to and from the other systems. Client software, including DAM, could send queries in DAL's standard language which would then be translated and executed regardless of the back end database. In contrast, ODBC was developed from the start to be a SQL based system, based on the standardized Call Level Interface from X/Open (now part of the Open Group). Under OBDC, every data source was made to look like a SQL server. For serverless sources, such as text files, a local SQL parser would interpret the commands and read the file. Under ODBC, all data source drivers are expected to understand SQL and translate it to the local dialect if needed, as well as convert data into standard formats when it is returned. This difference made DAM much less useful than ODBC in practice. Since it was expected that DAL would be providing query standardization, DAM had no layer similar to ODBC's for translating different dialects. In order for DAM to be truly useful, the user also had to buy and install a DAL server for their particular database. DAL was generally known to be slow and expensive, seriously degrading DAM's overall value. Further, DAM did not standardize the language for accessing non SQL data sources; an adaptor for a text file might use a non SQL language, or a completely function call based system instead. Nor were any simple interfaces for text files or similar data sources included with basic DAM installs.

Қолданылуы

DAM-нің негізгі клиенттерінің бірі Apple-дің деректерді басқару және жылдам қолданбаларды әзірлеу жүйесі HyperCard болды. HyperCard-тың тамаша формалар жүйесін DAM деректерімен үйлестіру нәтижесінде деректермен басқарылатын GUI қолданбалары пайда болды – мұндай нәрсе бұрын көрілмеген. Жүйенің ең көп таралған демонстрациясы Baskin Robbins дерекқорына сұраныс жіберетін HyperCard стегін көрсетті, бұл бұрын мүмкін емес еді, себебі әр аймақтық бөлім өз дерекқоры серверлерін пайдаланды, енді DAL оларды біріктірді. Қоймадағы тауардың ағымдағы жағдайын көрсететін графикалық дисплейде мұздықтың бірнеше түрлерін сүйреп, қосымша тауарға тапсырыс беруге болады. Жүйе соншалықты әсерлі болды, басқа дерекқоры жеткізушілері де осыған ұқсас жүйелерді ұсынуға тырысты; Oracle Corporation дереу Spinnaker Software-ден PLUS сатып алып, оны алдымен Oracle Card, содан кейін Oracle Media Objects ретінде шығарды. Басқа компаниялар да осы жолмен жүрді, көп ұзамай оқиғаларға негізделген дерекқоры интерфейсі көптеген жүйелердің стандартты мүмкіндігіне айналды. Осы жүйені тағы да бірқатар қолданбалар пайдаланды, мүмкін, Microsoft-тың Office өнімдері ең жиі қолданды. Басқа жағдайларда DAM қолдауы өте сирек болды және өнім кеңінен таралған жоқ. Бұл, әдетте, DAM жүйесінің толыққанды болмауына байланысты болды; көп жағдайда DAL аралық бағдарламасын қажет етуі және төмен құнмен сұраныс құжаттарын құрастырушылардың жетіспеуі (бірнеше қымбаттары болды) DAM-ді пайдаланудың құнын жоғарылатты. DAM бойынша жұмыс 1990 жылдардың ортасында аяқталды және Mac OS X шығарылғанға дейін толығымен тоқтатылды. Біраз уақыт бойы ODBC-нің «классикалық» Mac OS нұсқасы қолжетімді болды, бірақ қолдауы шектеулі болды. OS X 10.2 Jaguar нұсқасынан бастап Apple iODBC кросс-платформалық ODBC драйверлерінің нұсқасын таратуды бастады. OS X 10.4 Tiger нұсқасынан бастап Apple Core Data деп аталатын жаңа және «жоғары деңгейдегі» жүйені енгізді. Core Data әзірлеушілерге деректерді SQLite-ке өңдеу үшін сериалдауға мүмкіндік береді, бұл SQL емес дерек көзімен қолданылған кезде ODBC-ге ұқсас.

One of the major clients for DAM was HyperCard, Apple's data manager/rapid application development system. Combining HyperCard's excellent forms system with data from DAM resulted in something that no one had ever seen before data driven GUI apps. The most common demo of the system showed a HyperCard stack querying a series of Baskin Robbins databases, formerly impossible because each regional area used their own database servers which DAL now combined into one. Reorders for more stock could be made by dragging a series of ice cream scoops on a graphical display of the current warehoused inventory. The system was so impressive that it made other database vendors scramble to provide similar systems; Oracle Corporation immediately purchased PLUS from Spinnaker Software, releasing it first as Oracle Card, and then Oracle Media Objects. Other companies followed similar routes, and soon the event driven database front end was a standard feature of most systems. A number of other applications also used the system, perhaps ironically Microsoft's various Office products doing so with the most regularity. Other than that DAM support was fairly rare, and the product did not see widespread use. Perhaps much of this was due to the incomplete nature of the DAM system as a whole; the need for DAL middleware in most cases, and the lack of low cost query document builders (there were some expensive ones) made the overhead of using DAM quite high. Work on DAM ended in the mid 1990s, and disappeared entirely sometime before the release of Mac OS X. A "classic" Mac OS version of ODBC was available for some time, although support was limited. Starting with the release of OS X 10.2 Jaguar, Apple started distributing a version of the iODBC cross platform ODBC drivers. Starting with OS X 10.4 Tiger Apple has introduced a new and much "higher level" system known as Core Data. Core Data allows developers to serialize data into SQLite for processing, similar in concept to ODBC when used with a non SQL data source.